Big update to prettier-extension-monkeyc

flocsy🤠 said:

I have now a warning that I can't understand

Fixed in v2.0.23

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:

Yes, this is mostly just something I haven't got around to... I implemented all the binary operators that ended up being applied to two constants in *my* projects, and intended to come back and add the rest later. But I haven't got around to it yet.

So right now, I'm not constant folding any comparisons (that should be fairly easy to implement), or logical && and ||. I deliberately left out the logical operators because of all the bizarre things that happen with different types. eg if SPACE_BETWEEN_GAUGE_AND_LABEL is 5, it looks like I can optimize this to "if (true && mShowZoneColor)", which then becomes "if (mShowZoneColor)". But if mShowZoneColor is null (or Float, or pretty much anything other Boolean, Number or Long), the original code crashes, while the optimized code does not (and remember that my optimizer currently knows nothing about types, so no matter how its declared, I have no idea what type mShowZoneColor is going to be.

So yes - comparisons should be easy, I'd just forgotten about them. Logical operators maybe a bit harder, but there's definitely no problem when the first argument to && is false, or the first argument to || is true; so I should at least be able to handle those...

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.