Big update to prettier-extension-monkeyc

OK, this work in launch.json, but that's not the way I usually use it (I use Ctrl+Shift+P > ...) so I guess that'll only work after it's being added to the settings.
However this was enough to find a bug, however one that seems to be not mine but Garmin's and maybe even a new one:
My code:

            var msg = new Ant.Message();
            msg.messageId = Ant.MSG_ID_BROADCAST_DATA;

optimized code:

        var msg = new Ant.Message();
        msg.messageId = 78 as Toybox.Ant.MessageId;

Error message:
ERROR: fenix6: /home/gavriel.fleischer/private/garmin/ExtHRM/bin/optimized/group000-debug/source/source/ExtHRMApp.mc:121,8: Cannot assign value '$.Toybox.Ant.MessageId' to member ':messageId'.

According to the documentation messageId is Number?, however the optimized code thinks MSG_ID_BROADCAST_DATA is Toybox.Ant.MessageId . Is this a bug in the optimizer? I don't see such type in the docs. Or it's the way it's declared in the sdk?

joshuahxh said:

Just installed this extension, and tried it on one of my project

Sorry, this is embarrassing. I didn't test the latest release on windows. For now you can downgrade to v2.0.34 (open the extensions panel on the left, then click the cog-wheel icon next to "Prettier Monkey C", and select "Install another version...").

I'll try to get a fixed version out later today.

flocsy🤠 said:

According to the documentation messageId is Number?, however the optimized code thinks MSG_ID_BROADCAST_DATA is Toybox.Ant.MessageId . Is this a bug in the optimizer? I don't see such type in the docs. Or it's the way it's declared in the sdk

This is exactly the same bug. If you look at the documentation for MSG_ID_BROADCAST_DATA, above the table you'll see "MessageId", which indicates that it's an enum of type "MessageId". You can also see that by looking in sdk/bin/api.mir.

So if I do:

class Foo {
  var x as Ant.MessageId;
  var y as Number;
  function initialize() {
    x = Ant.MSG_ID_BROADCAST_DATA; // works
    x = 78; // fails
    x = 78 as Ant.MessageId; // works
    // but
    y = Ant.MSG_ID_BROADCAST_DATA; // works
    y = 78; // works
    y = 78 as Ant.MessageId; // fails
  }
 }

The Garmin type checker treats Ant.MESSAGE_ID_BROADCAST_DATA as a special type that can be used anywhere a Number OR an Ant.MessageId can be used. But there is no other way to produce such a type (note that "Ant.MessageId or Number" doesn't do it - that type can't be assigned to *either* variable).

The fix is to write "msg.messageId = Ant.MSG_ID_BROADCAST_DATA as Number" in your original code. Or "msg.messageId = Ant.MSG_ID_BROADCAST_DATA | 0" if you prefer.

v2.0.35 is out.

• Fixes windows issues
• Propagates `:typecheck(false)` when inlining
• Adds new setting `prettierMonkeyC.useLocalOptimizer` which can be used to prevent a locally installed copy of @markw65/monkeyc-optimizer from being used (this could be useful if you wanted an export task that uses a pinned version of the optimizer, for reproducibility, while all other build tasks used the latest version of the optimizer)
• Adds new setting `prettierMonkeyC.typeCheckLevel` which can be used to set the level to use for optimized code independently of `monkeyC.typeCheckLevel`

I didn't have the time to try it yet, but I wonder: doesn't propagating type check have the side effect that we might miss type errors in function a() because it inlined function b() that disabled type check?

This works.  And one of my prg got saved 5k bytes with your optimized codes.  Thank you!

flocsy🤠 said:

doesn't propagating type check have the side effect that we might miss type errors

Yes, of course. But presumably you build the unoptimized code during normal development, so the type checker does run on the original code.

Since Garmin's type checker can't be disabled on an expression.by expression (or even statement by statement) basis, there doesn't seem to be an alternative. And other than the one issue I mentioned above, I'm not aware of any case where the original code type checks, but the optimized does not; and that one issue really is a problem with the type checker, not with the optimizer (since the optimized code really is correct).

There were cases when I only realized some problem in one device that i did not check manually because it failed to compile. I guess similarly i could theoretically miss some type checker thing. So maybe best practice from now to 1st export (all devices) without the optimizer and only then with it.

v2.0.37 is out.

• More improvements to analysis of code in resource files, so that (I think) the optimizer sees all the code involved in the project (this should enable slightly better optimizations in future)
• Upgraded the constant folding code to handle most legal combinations. I don't fold Float or Double vs String because of bugs in the latest monkeyc compiler.