Big update to prettier-extension-monkeyc

flocsy said:

I have now a warning that I can't understand

Fixed in v2.0.23

My wish for this x-mas is that for every 10 bugs you fix in less than a day Garmin fix 1 bug that is known for at least a year :)

FlowState said:

Personally I think Garmin should just fix their type system so that something like if (s != null) narrows types properly

This one actually does work, I believe, if s is a local.

But things like "s != null && foo(s)" (where foo expects a String) don't work in the currently released sdks (but do work in the Compiler 2 Beta). But there are plenty of places where the person writing the code knows that a variable is non null, but the compiler can't know that.

s != null && s.foo() works in Compiler 2 Beta, but if (s != null) {s.foo()} doesn't work as far as I remember, I also added some info about it on the existing bugreport.

flocsy said:

but if (s != null) {s.foo()} doesn't work as far as I remember

My experience is that really simple checks like the above do work, even for non-locals. But equivalent things which work for locals don't necessarily work for non-locals.

eg I just tried:

    var mStr as String? = null;
    function bar(s as String?) as Void {
        if (s != null) {
            s.find("x"); // works
        }
        if (mStr != null) {
            mStr.find("x"); // works
        }
        if (s == null) {
            return;
        }
        s.find("x"); // works
        if (mStr == null) {
            return;
        }
        mStr.find("x"); // fails
    }

ok, here's one that doesn't:

feature-request: add more optimizations related to evaluation of constants. For example I have code like:

Version 2.0.24 is out.

This release adds various features:

•  All binary operators can now be constant folded (for suitable argument types)
•  Functions that can be inlined in assignment scope, can now also be inlined in declarations.
•  There’s a new size based partial redundancy elimination pass.
•  There’s a new command “Clean Optimized Project” in the VSCode command palette that will remove the build artifacts; useful if you have a monkey.jungle that includes all .mc files, including ones in bin.

I noticed that a reference to a non-local variable takes 8 bytes, plus 6 for each component (so gFoo takes 8, MyModule.gFoo takes 14), while a reference to a local variable only takes 2 bytes. So if there are two or more uses of.a global in a function, and the optimizer can prove the value doesn’t change, its worthwhile to load the value into a local (10 bytes) and replace each use with a use of the local (saving 6 bytes per use). So I wrote the PRE pass to do that. Currently, it assumes that all non-locals change at all function/method invocations. This is suboptimal, and analyzing each function to determine what it might change will be coming soon.

While working on that, I noticed that even literals are quite expensive; each reference to a number or string adds 5 bytes, so if, for example, the number 0 is used 3 times in a function, thats 15 bytes. But if I read it into a local, and then use it 3 times thats 7 + 3*2 = 13 bytes - so again, I can save space if its used 3 or more times. And this time, I don’t have to worry about anything else changing the value…

For my code, this takes about 150 bytes off of a program with a 10k code footprint, on top of the 1k it was already removing. I think once I fix it to be less conservative, it might get another 50-100 bytes.

This pass was quite tricky to implement. Since I’m constrained to output monkeyc (rather than some lower level byte code), it can be hard to find a good place to insert the assignments to the new variables; and sometimes, it's simply not possible. I’ve spent a while ironing out all the bugs I could find, but I’m still concerned that it could do unexpected (and incorrect) things. So for now, it's off by default. There’s a new prettiermonkeyc.sizeBasedPRE setting (Cmd/Ctrl-, then type sizeBasedPRE into the search field), which can be overridden in tasks.json, or launch.json.

Can you double check the "Functions that can be inlined in assignment scope, can now also be inlined in declarations."? I think it has a bug.

1 Downloaded the new version, and turned on the size based pass, and I saw the code shrinked. But when I changed the code from:

var x;
x = foo();

to:
var x = foo();

then the code size grown. It's because an old bug is back:

(:inline)
function foo() {
   bar();
}

(:inline)
function bar() {
 ...
}

both foo and bar are inlined, but the original bar is not deleted.