Big update to prettier-extension-monkeyc

Right, the problem here is that I had to hardcode the type of Rez.Strings.*, because there's nothing in the sdk to tell me what it is (in hindsight, I suppose I could have looked at the signature for Application.loadResource, and picked out the type of its argument; but that didn't seem like something that was going to change).

On the other hand it gets the signature for Application.loadResource from <sdk>/bin/api.mir, and under 7.x that says it expects a ResourceId. Hence the "error".

I just need to make it give the correct type to Rez.Strings.* based on what the sdk says.

            (:no_inline)
            public function computeImpl(info as Activity.Info) as ValueType {
                return null;
            }

            // Calculate the data to display in the field here
            public function compute(info as Activity.Info) as Void {
                var value = computeImpl(info);
                var currentValue = self.value;
                if (value != null ? !value.equals(currentValue) : currentValue != null) {
                    log("compute3: " + value);
                    self.value = value;
                    WatchUi.requestUpdate();
                }
            }

So this code is part of what in other language would be called an abstract class. computeImpl is what should be overridden in the child class. Obviously the "var value = computeImpl(info)" shouldn't be eliminated, but this is how it is optimized:

      // Calculate the data to display in the field here
      function compute(info as Activity.Info) as Void {
        if (self.value != null) {
          log("compute3: null");
          self.value = null;
          WatchUi.requestUpdate();
        }
      }

Now let me add 2 pieces of information:
1. IMHO computeImpl shouldn't be eliminated even if it's:

            public function computeImpl(info as Activity.Info) as ValueType {
                return null;
            }

just because it's public!

2. it certainly shouldn't be inlined when (:no_inline) annotation is present.

It depends. If there's no overriding implementation then what's going on here is fine. And I definitely have checks for that - although if you're saying that you do have another class that overrides it, and this is happening, then that's obviously a bug [Ok, I just checked, and yes, it does happen regardless - so definitely a bug].

As far as the no_inline goes, I don't think that's actually a thing. The optimizer doesn't check for no_inline anywhere. I think if you've been using it, it's just documentation. Or maybe I promised it at some time and forgot to implement it :-)

But I do have a child class that overrides computeImpl. That's the reason I know about the bug, because I don't see my data on the screen

That's why I wrote:

> Ok, I just checked, and yes, it does happen regardless - so definitely a bug

Anyway, I found the bug. As I said, there was already a test for no overriding functions, but it wasn't being checked everywhere. There was one path into the inliner that didn't check it. So it's basically a one line fix.

I'm going to write some more tests, and then see what I can do for the stack overflow issue.

New version v2.0.75 [edit: 2.0.76] is out.

• Fixes the type analysis bug reporting an error for Application.loadResource(Rez.Strings.Foo) in sdk-7.x
• Fixes an incorrect inlining issue when the callee might be overridden
• Fixes a post build optimizer issue that could cause stack overflows for large, initialized arrays

Something isn't right. 2.0.75 was released 2 days ago, that's my current one.

update: OK I see now 2.0.76, and it indeed works.

This one was because the post build optimizer reduces the size of array initializers by pushing array/index pairs onto the stack in a loop, and then doing the assignments one at a time in reverse order, cleaning one array/index pair per assignment. This saves 7 bytes per element, with an overhead of 22 bytes for the loop - but it temporarily pushes 2 items for each array element onto the stack.

It looks like data fields only get 128 stack slots - and obviously a few are already in use - so it started to run into problems with around 60 elements in the array. Watch Apps have much bigger stacks, but for now I'm limiting the number of elements to 50 less however much the optimizer knows is already on the stack, regardless of the type of app being built.

It would also be possible to push the initializers onto the stack first, and then do the assignments in a loop. That would only require one stack slot per array element, but would make the loop more complex (I can't see a way to do it without introducing a couple of new local variables). I might look into that.

I haven't check this in SDK7, but in 6 now I get this underlined with red: