Big update to prettier-extension-monkeyc

You didn't forget to import anything. This code:

import "Toybox.WatchUi";

function getMenu() as Menu2 {
    return new Menu2({:title=>"My Menu2"});
}

compiles and type checks with compiler1 and compiler2, but if you compile it with compiler1, and try to run it, it will crash at the "new Menu2". If you want it to work with compiler1, or with -O0, you need to say "new WatchUi.Menu2(...)". There is nothing you can import that will fix it.

I'm finding that a number of diagnostics seem to need more explanation, so I'm hoping I can make them link to a wiki page - but I've not really looked into that yet. For this specific warning, I can probably include the module that you need to add in order to fix the issue (ie WatchUi in this case) to make it a bit clearer.

flocsy🤠 said:

DataFieldAlert will only be found when compiled with compiler2 at -O1 or above

Just another note on this. I've been playing with 4.1.2 beta 2 today, and it seems that that version uses compiler2 regardless of the optimization level. So this will be less of an issue in future.

Version 2.0.41 is out.

This extends the type analysis, and adds various optimizations that were dependent on it.

In addition to using the inferred types for opimization, this version also adds a lot of type checker warnings, and runs the analysis in the background as you type. It doesn't yet cover everything that Garmin's type checker does (in particular, it doesn't warn about the types of arguments to binary or unary operators), but it does cover a number of things that Garmin's does not (eg inferring types for Array and Dictionary literals).

flocsy🤠 said:

wow. big chaos

Well, I've certainly seen cases like that while working on the type analysis, but I thought I'd found and fixed everything.

If I take your code, make minimal changes to remove the "..." etc, I get no errors or warnings:

// B.mc
import Toybox.Lang;
import Toybox.Math;

class B {
    public function add(d as Number?) as Void {}
    var mArr as Array<Number> = [1];

    public function remove(n as Number) as Void {
        var s = mArr.size();
        var remove = n <= s ? n : s;
        for (var i = 0; i < remove; i++) {
            add(null);
        }
    }
}

// C.mc

import Toybox.Ant;
import Toybox.Lang;

class C {
    private var mB as B = new B();

    public function c() {
        d(42);
    }

    (:inline)
    hidden function d(beats as Number) {
        var b = mB;
        if (beats > 1) {
            b.remove(beats);
        }
    }
}

Looking at the generated code, I saw that both c() and d() got optimized away. So I added (new C()).c() to my App's initialize function. Now I get what I'd expect, but still no errors/warnings of any kind.

If I change it so that beats is Number or Float, then I get the error

Argument 1 to $.B.remove expected to be Number but got Number or Float

similar to what you saw, but none of the other errors.

Can you post something that actually compiles and produces the errors?

The next issue is probably a feature, not a bug :) It tells me that something that I declared and assumed can only be String or Number can also be Null. I tried to see why, and it is kind of true. It will never be null but the optimizer can't know it because it's tricky:

var mS as String?;
var mT as Number = -1;

(:inline)
function foo() as Number or String {
  // some code, then 4 inlined function calls:
  f1();
  f2();
  f3();
  f4();

  // here starts the problematic part, and lasts until the end of the function:
  var s = mS;
  var t = mT;
  var r;
  if (cond1) {
    if (cond2) {
      r = s;
      if (r == null) {
        r = loadResource(Rez.Strings.foo) as String;
      }
    } else {
      s = null;
      r = getString();
    }
  } else {
    if (t == 0) {
      s = loadResource(Rex.Strings.bar) as String;
    }
    if (t < 5) {
      t++;
      r = s as String;
    } else {
      if (t == 5) {
        s = null;
        t++;
      }
      if (cond3) {
        r = h; // Number
      } else {
        r = "--";
      }
    }
  }
  mT = t;
  mS = s;
  return r;
}

private var mArr as Array<String>;
function setArr(arr as Array<String>) {
  mArr = arr;
}

function getString() as String {
  if (mArr == null) {
    setArr(["a","b","c"]);
  }
  return mArr[mI];
}

So I can understand why the optimizer thinks that foo() can also returns Null. However it does never do that because of the inner state of the class... So I guess I can do one of 2 things:

1. you tell me what annotation to add on foo() (I guess either :typecheck(false) or the one you once told me already exists for your tests) - and I understand that using these annotations will probably have a negative effect on the optimizer and thus on the code size (especially that foo is even bigger than shown above) but I can test it and compare the results to the other option(s)

2. I can probably change the code in foo() in a way that it'll be a bit bigger code size but explicitly ensures that r can't be null at the last line - which will add to the code size when not using the optimizer but probably will be worth compared to the 1st option because the optimizer will be able to gain more in foo()

BTW foo() is inlined in a function and foo also calls at least 4 other inlined functions - but all those are before the problematic part of the code. So if the annotation on foo will cause the optimizer to not (or less) optimize foo, then maybe I'll try to refactor foo such a way that all the problematic part goes to another function, so the bad effect of the annotation doesn't propagate to the other parts of the code, and it'll be something like:

(:inline)
hidden function foo() as String or Number {
  // some code
  f1();
  f2();
  f3();
  f4();
  problematic();
}

(:inline)?
(:no_inline)?
(:typecheck(false))?
(:other_annotation_you_tell_me)?
fidden function problematic() as String or Number {
  ...
}

I'll try. The above code was not tested it was just manually shrinked from my code as an example... Last time I tried to give you the minimal example I deleted all my files accidentally... I'll try to be safer now.

UPDATE:

I found 1 small change that caused it to compile with both Propagate Types, Size Based PRE and Trust Declared Types enabled. (BTW It has a very bad result, I'll send them below)

Here's a more detailed version (still not tested though) that includes the problem and the fix that makes it compile:

//// B.mc
import Toybox.Lang;
import Toybox.Math;

class B {
  public function add(d as Number?) as Void {
  	...
  } 

  public function remove(n as Number) as Void {
    var s = mArr.size();
    var remove = n <= s ? n : s;
    for (var i = 0; i < remove; i++) {
      add(null);
    }
  }
}

//// C.mc
import Toybox.Ant;
import Toybox.Lang;

class C {
  private var mB as B = new B();

  public function c() {
    d();
  }
  
  (:inline) hidden function d() {
    var b = self.mB;
    var beats = ...;// (Number);
    var t = 987;

    // I assumed this is Number as a result of integer arithmetic:
    var problematic = (t * 1000) / 1024;

    // my fix adds a few bytes of code but makes it compile:
    var problematic = ((t * 1000) / 1024).toNumber();

    if (cond1) {
      b.add(problematic);
    }
    if (beats > 1) {
      b.remove(beats);
    }
  }
}

So it looks as I wrongly assumed: 100/3 is Number and 100/3.0 is Float. Either I am wrong or the assumptions of the optimizer are wrong about this.

I think for the next release I’ll just use typecheck(false) to disable diagnostics locally. There’s no reason for that to affect optimizations- it will still use whatever it can deduce/prove. It just won’t tell you when that looks problematic. 

Sorry I was missleading: So after this "fix" it still gives most of the errors/warnings but then it does compile and run.

Away from my computer at the moment, but I think this is a bogus error reported during inlining. 

just after inlining, there is no type info for the inlined code; but the optimizer thinks there should be, and reports errors as if there was. To avoid that, I try to avoid running the optimizer on the just-inlined code until the next time type propagation runs. But I think you’ve found a case where somehow the optimizer does see the untyped code. 

note that it should never make bad (as in incorrect) optimization decisions in that case, but it does spit out some strange warnings. 

the simple fix is to do a separate pass at the end to report all diagnostics; but that might miss cases where code has been optimized away entirely.