Big update to prettier-extension-monkeyc

flocsy🤠 said:

wow. big chaos

I've found another edge case that can trigger the behavior you saw. Keeping your B.mc, I've made this change to C.mc

import Toybox.Ant;
import Toybox.Lang;
import Toybox.Application;

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

    public function c(x as Number or Float) as Number {
        return d(42);
    }

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

ERROR> fenix5xplus: source/C.mc:18:13: $.Toybox.PersistedContent.remove expects 0 arguments, but got 1
ERROR> fenix5xplus: source/C.mc:18:13: $.Toybox.PersistedContent.Waypoint.remove expects 0 arguments, but got 1
ERROR> fenix5xplus: source/C.mc:18:13: $.Toybox.PersistedContent.Course.remove expects 0 arguments, but got 1
ERROR> fenix5xplus: source/C.mc:18:13: $.Toybox.PersistedContent.Workout.remove expects 0 arguments, but got 1
ERROR> fenix5xplus: source/C.mc:18:13: $.Toybox.PersistedContent.Route.remove expects 0 arguments, but got 1
ERROR> fenix5xplus: source/C.mc:18:13: $.Toybox.PersistedContent.Track.remove expects 0 arguments, but got 1

basically, I've added a reference to b.K (note that any global namespace name would do). Normally, when you access a member variable, the type analyzer will refine the type of the object based on the property it sees. In this case, thats the wrong thing to do, and end up deducing that b has the "empty" type, and then have no idea how to lookup b.reduce, so assume it could be any of the reduce functions, and then warn because most of them need different arguments.

I suspect that this isn't your problem though, because Garmin's type checker will complain that K doesn't exist on B (although if you disable Garmin's type checker, the code runs correctly).

Yeah, I don't think this is my case.

I found another bug:

class D extends DataField {
    function onUpdate(dc as Graphics.Dc) {
        var backgroundColor = getBackgroundColor();
        var foregroundColor = backgroundColor == Graphics.COLOR_BLACK ? Graphics.COLOR_WHITE : Graphics.COLOR_BLACK;
        dc.setColor(foregroundColor, backgroundColor);
        dc.setColor(Graphics.COLOR_WHITE, Graphics.COLOR_BLACK);
    }
}

The editor shows backgroundColor in setColor() as red:
Argument 2 to $.Toybox.Graphics.Dc.setColor expected to be Number or Number as Toybox.Graphics.ColorValue but got Number or Enum[pmc-analysis]

another one:

    var cond1 as Boolean = true;
    var cond2 as Boolean = true;
    var mA as Number = 0;
    function a(dc as Graphics.Dc) as Void {
        var zero = 0;
        var hJ = Graphics.TEXT_JUSTIFY_CENTER;
        var vJ = Graphics.TEXT_JUSTIFY_VCENTER;

        if (cond1) {
            hJ = Graphics.TEXT_JUSTIFY_RIGHT;
        } else {
            hJ = Graphics.TEXT_JUSTIFY_LEFT;
        }
        if (cond1) {
        } else {
            vJ = zero;
        }
        mA = hJ;
        mA = vJ; // Invalid assignment to mA. Expected Number but got Number or Enum[pmc-analysis]
        mA = hJ | vJ; // Invalid assignment to mA. Expected Number but got Boolean[pmc-analysis]
    }

flocsy🤠 said:

Yeah, I don't think this is my case.

What about this one then... could it be the same "const" bug from earlier?

If I change your original example to 

class C {
    private const mB = new B();

i.e a const without a declared type (as opposed to the var with a declared type) then the bug repros before my const fix, and not after...

flocsy🤠 said:

I found another bug:

I can repro. 

    const Z = -1.0;
    var mZ as Float = 0.0;
    hidden function f() as Void {
        var fZ = Z;
        mZ = fZ; // Invalid assignment to mZ. Expected Float but got Any[pmc-analysis]
    }

it's not a const in my real code, but I'll try to change it to a const, cause it could be, I never change. Is there any difference "nowadays" between a var and a const in the class level? I think a few compiler versions earlier I saw that using const makes the code bigger so I stopped using consts in classes.

This one I'm not sure if it's a bug or a problem in the Monkey C language:

    function x() {
        Ant.GenericChannel.initialize(
            method(:onMessage), // here 2 warnings
            new Ant.ChannelAssignment(Ant.CHANNEL_TYPE_RX_NOT_TX, Ant.NETWORK_PLUS)
        );
    }
    public function onMessage(msg as Message) as Void {
    }

flocsy🤠 said:

Do I need to add: "as Method<(Toybox.Ant.Message) as Null>"

That's not the correct syntax - I should fix the error message.

I think it would be "as Method(m as Toybox.Ant.Message) as Null". But that suggests that Garmin's compiler is inferring the type by looking up the method (since presumably it doesn't give an error). I can certainly do the same...