Big update to prettier-extension-monkeyc

I think that's it. Since they're now enforcing the new SHA256 signatures when side-loading, they're also enforcing them in the simulator.

It turns out I had a bug that was preventing the optimizer from actually generating the SHA256 signatures. After fixing that, everything seems to work again.

I'm running tests, and will hopefully upload a fixed version shortly.

v2.0.118 is out.

This fixes a bug that was preventing the new SHA256 signatures from being written in the optimized binaries. sdk-8.2.2 won't simulate binaries that don't have a SHA256 signature.

I'm trying to reproduce this, and haven't been able to. Is there something else in your project? Files in source for example?

Could you file an issue at https://github.com/markw65/monkeyc-optimizer/issues and include a zip file (or a link to a GitHub repo) with a complete project?

The rest of the files are generated by "Monkey C: New Project" using "Watch App" template.

Please, try this: SampleApp.zip. I generated a new project outside any workspace and copied the code from my post. All user and folder settings are default. VS Code plugin fails.

P.S., I downloaded my own zip, unpacked it to /tmp, cloned monkeyc-optimizer, ran npm install and npm run build-debug, then node test/test.js --analyze-only --jungle /tmp/SampleApp/monkey.jungle, and it failed the same way as before in expandTypedef and subtypeOf.

Thanks - that does it.

Here's a simpler, standalone repro:

import Toybox.Lang;
typedef Tuple1 as [Number, Array<Tuple1>?];
typedef Tuple2 as [Number, Array<Tuple2>?];

var x as Tuple1 or Tuple2 = [42, Null];

The problem is that when it tries to compute A or B it first tries to determine if one is a subtype of the other - in which case there's nothing to do. In the case of two distinct self-referential typedefs, it "keeps going" until it finds a difference. But at every level these two types are the same, so it keeps cycling through.

In your case, analysis sees both definitions of Tuple, so a declaration involving Tuple tries to use the union of the two definitions. A build would only see one of the definitions, and shouldn't have this issue. I have a separate project in progress to try to fix analysis to be more selective about which types it considers "possible"; that would fix your example, but not the one above.

I think I need to keep a map from "active" typedefs to a set of things they're being compared against, and if I ever revisit a typedef and the set already contains the thing being compared, I can bail and say the two types are the same. I think that's sufficient to cover arbitrarily complex cycles - but it's making my head hurt...

And I think this is mostly self-imposed. The last time I checked, Garmin's type checker treats uses of a typedef name inside its definition as "Any". So Tuple1 above is just [Number, Array?], presumably to avoid this issue...

v2.0.119 is out.

It fixes this infinite recursion issue, and also an issue where the inferred type of an array/object containing a null was too broad.

Thanks, call stack size error seems to have disappeared from my real project. But it still fails in SampleApp. I tried "Restart Extension Host" multiple times after updating to 2.0.119, but it didn't help.

It looks like I got lots of new errors related to enums. Maybe, I'm wrong, and they are not caused by this fix, since I used PMC with "prettierMonkeyC.disableAnalysis": true for a while because of this infinite loop.

Could you also take a look at this: SampleWorkspace.zip?

And is it just me, or the analysis is really slow for this workspace? I have multiple sets of generated sources (that are mostly duplicates of each other) for different devices since barrels don't really support exclude annotations, and I have to avoid this by using different sourcePaths.