Big update to prettier-extension-monkeyc

markw65 said:

Garmin's compiler now does the same thing

Could you, please, add an option to disable this (or disable automatically based on compiler version)?

I have lots of warnings for such cases:

enum Values {
    VALUE_1 = false;
    VALUE_2 = 0;
}

function processBooleanValue(value as Boolean) as Void {}
function processNumberValue(value as Number) as Void {}

function doThings() as Void {
    processBooleanValue(VALUE_1);
    processNumberValue(VALUE_2);
}

as optimizer does the following:

typedef Values as Boolean or Number;

function processBooleanValue(value as Boolean) as Void {}
function processNumberValue(value as Number) as Void {}

function doThings() as Void {
    processBooleanValue(false as Values);
    processNumberValue(0 as Values);
}

that causes:

Passing 'PolyType<$.Toybox.Lang.Boolean or $.Toybox.Lang.Number>' as parameter 1 of non-poly type '$.Toybox.Lang.Boolean'.
Passing 'PolyType<$.Toybox.Lang.Boolean or $.Toybox.Lang.Number>' as parameter 1 of non-poly type '$.Toybox.Lang.Number'.

Hmmm. To me it looks a bit strange what you do. Why do you mix types in an enum?

I know it looks weird, but I want these values to be grouped to a named set of constants. In other functions I use this values in a more natural way - I have "value as Values" function argument and process them using switch.

I have about 5 such enums, and most of them are from my early days with Monkey C. At first there were only numbers in these enums, but later I added booleans there. Typically, these enums represent something similar to "don't do this", "do this 1 time", "do this 2 times", "...", "do this as many times as necessary". I could've used negative values for first and last cases, but booleans look more natural to me here. Probably, I should change this, but "What do we say to the god of refactoring?" "Not today".

If you phrase it this way, then my answer is "yes, probably, you're right".

I see this as a series of facts: "Monkey C allows you to create such enums", "Monkey C allows you to pass enum values to functions with enum-typed arguments", "Monkey C allows you to use enum values as basic-typed constant values and pass them to functions with basic-typed arguments", and I use all of these in my code, that is fully valid for "-l 3" compiler option.

If markw65 thinks, that optimizer shouldn't or can't process such cases (or give a possibility to leave things as they are), then I can live with this as I do now. I've asked only because the "replace enums with typedefs" functionality was mentioned in the discussion, and this optimization (that is obsolete now) sometimes modifies code in the way it cannot be compiled without warnings anymore.

Ok, you're right, Somehow I missed the part that the unoptimized code works

9811827 said:

If markw65 thinks, that optimizer shouldn't or can't process such cases

Sorry, I've not been getting notifications for some reason, and didn't see this until now.

This really comes down to issues in Garmin's type checker, such as this one.

In both that case, and yours, Garmin's type checker is happy to accept 'enumValue', but rejects 'enumValue as enumType'

But most of the problems I was trying to work around by inserting those type assertions are for cases when the enum type doesn't actually get removed from the program (eg when its a Toybox type), and when variables or arguments are declared as taking that enum type. In that case, the substituted enum values have to be cast back to the enum type.

But I think in the case that the whole enum is removed, it's always possible to just substitute the values without a cast. So there's probably an easy fix for your case.

But note that you can always just set prettierMonkeyC.typeCheckLevel="Off". All that does is turn off Garmin's type checker when it's building the optimized source. It doesn't affect what my extension reports in the live analysis, or at build time, and it (obviously) doesn't affect what Garmin's type checker reports when it's building the unoptimized source. So as long as you sometimes build the unoptimized project, you really don't lose much...

I see why I wasn't getting notifications. I created a test garmin connect account so I could upload .FIT files generated by a project I'm working on without them getting mixed up with my actual workouts, but that meant I was logged in to the forums with that account too. "3647548" is me.

3647548 said:

This really comes down to issues in Garmin's type checker, such as this one.

Yes, thanks, I've seen it before in plugin's readme, and at first thought this was it. But later I saw yours

    foo(Zero as Foo); // Works, as expected
    foo(0 as Foo);    // Works, as expected

and considered that my case is something different, as I have warnings for arguments, while you haven't. If this is all the same, then OK.

3647548 said:

cases when the enum type doesn't actually get removed from the program (eg when its a Toybox type)

Have you seen them in modern SDK versions? I've inspected assembler.txt from "--debug-log-level 3" for unoptimized source recently and haven't found any mentions of both custom and Toybox enums, as all of them were replaced with their values in the bytecode, including FontDefinition, ColorValue and TextJustification enums. Are there any others, that stay in bytecode as references to values and not as values themselves? I use "-O3" optimization level, btw (and don't know, why would anyone ever want to use other values, as there, probably, wouldn't be any speed optimizations due to the larger amount of bytecode is being generated, that contains the same set of opcodes as "optimized for size" opcodes, and speed-optimized code is executed longer, as I think, then size-optimized basically due to the longer code, but this is the topic for separate discussion).

3647548 said:

prettierMonkeyC.typeCheckLevel="Off"

Thanks, I use strict level for unoptimized builds and informative (due to the issue above) for optimized ones already. I know, this is only a compile time thing, and PRG files will be the same for all of these levels, but I tend to keep the level as strict as possible to have some certainty that both I and the optimizer produce the safest possible code.

I would have some other question:

Simple Classes

In the past I avoided to create "simple" classes and used Arrays + static functions instead as this decreased the final watchface size. I'll give you an example:

class Point {

    var x as Numeric;
    var y as Numeric;

    function initialize(x as Numeric, y as Numeric) {
        self.x = x;
        self.y = y;
    }

    function rotate(center as Point, angle as Numeric) as Void {
	
		var a = Math.toRadians(angle);
	
		var s = Math.sin(a);
		var c = Math.cos(a);

		// translate point back to origin
		var x2 = x - center.x;
		var y2 = y - center.y;

		// rotate point + translate point back
		self.x = (x2 * c - y2 * s) + center.x;
		self.y = (x2 * s + y2 * c) + center.y;
	}
}

I would use following alternative instead:

module Point {

    function rotate(center as [Numeric, Numeric], angle as Numeric) as [Numeric, Numeric] {
	
		var a = Math.toRadians(angle);
	
		var s = Math.sin(a);
		var c = Math.cos(a);

		// translate point back to origin
		var x2 = x - center[0];
		var y2 = y - center[1];

		// rotate point + translate point back
		var x = (x2 * c - y2 * s) + center[0];
		var y = (x2 * s + y2 * c) + center[1];

        return [x, y];
	}
}

Do you think it would be feasible and possible to also optimize such classes, maybe with the help of manual defined annotations?

Utility Files

In the past I found out that it makes a difference if you have 1 file containing 100 functions vs 10 files containing 10 functions and the difference was quite large if I remember correctly (~2kB in my real life example back then). Files only containing static functions or containing a module could be summarized in a single file - is this something you consider? Any thoughts on this idea?