Big update to prettier-extension-monkeyc

I've posted about prettier-extension-monkeyc before, but I've added a bunch of new features that developers will probably like (well, I've been missing them, so maybe you have too).

The new features it implements for VSCode include:

  • Goto Definition. Point at a symbol, Ctrl/Cmd click, and it will take you to the definition. Or F12
  • Goto References. Right click on a symbol and select "Goto References". It will show you all the references. Or Shift-F12
  • Peek Definition/Peek References. Same as above, but in a popup window so you don't lose your place in the original document.
  • Rename Symbol. Right click on a local, function, class or module name, and select "Rename Symbol". It will rename all the references. It doesn't yet work for class members/methods.
  • Goto Symbol. Type Ctrl/Cmd-Shift-O and pick a symbol from the drop down (which has a hierarchical view of all symbols in the current file). This also appears as an outline across the top of the file.
  • Open Symbol By Name. Type Ctrl/Cmd-T, then start typing letters from a symbol name. A drop down will be populated with all matching symbols from anywhere in your project.

Older features include a prettier based formatter for monkeyc, and a monkeyc optimizer that will build/run/export an optimized version of your project.

[edit: My last couple of replies seem to have just disappeared, and the whole conversation seems to be in a jumbled order, so tldr: there's a new test-release at https://github.com/markw65/prettier-extension-monkeyc/releases/tag/v2.0.9 which seems to work for me on linux. I'll do more verification tomorrow, and push a proper update to the vscode store once I'm sure everything is working]

  • v2.0.116 is out.

    This fixed an issue with export, when the post build optimizer was enabled. Sdk-7.4.3 changed the .iq file format very slightly, but enough that the post build optimizer bailed with an exception. In addition, I didn't handle the exception correctly, and vscode thought the task hadn't finished, and would sit waiting forever.

  • v2.0.118 is out.

    • Fixes the parser to allow extra semi-colons after expression statements, and uncontrolled blocks, to match Garmin's
    • Fixes a crash resulting in strange error messages if there were no devices in the manifest
  •  I revisited one of my apps that I haven't worked on for a few months, and I get new errors (warnings?) like:

    ERROR> fenix6: Config.mc:30:5: Argument 1 to $.convertToString: passing Null or Boolean or Number or Long or Float or Double or Char or String or Array<Toybox.Application.PropertyValueType> or Dictionary<Boolean or Number or Long or Float or Double or Char or String, Toybox.Application.PropertyValueType> or Toybox.WatchUi.BitmapResource to parameter Null or Object is not type safe [more info: https://github.com/markw65/monkeyc-optimizer/wiki/Extra-Reference-Type-Checks-(prettierMonkeyC.extraReferenceTypeChecks)]
    inlined from $.toConfigStr in Config.mc:34:29
    ERROR> fenix6: Config.mc:30:5: Argument 1 to $.convertToString: passing Dictionary<Boolean or Number or Long or Float or Double or Char or String, Toybox.Application.PropertyValueType> to parameter Dictionary is not type safe [more info: https://github.com/markw65/monkeyc-optimizer/wiki/Extra-Reference-Type-Checks-(prettierMonkeyC.extraReferenceTypeChecks)]]
    inlined from $.toConfigStr in Config.mc:34:29

    1. I don't understand why there are 2 errors that are almost (but not exactly) identical

    2. I understand the explanation and the examples in github, but I don't understand why they apply here. My only guess is that your code sees value.toString() and thinks it can change value? Because I don't see why this is unsafe.

    monkey.jungle:

    fenix6.excludeAnnotations=$(fenix6.excludeAnnotations);no_ciq_2_4_0

  • ERROR> fenix6: MyField.mc:974:9: This comparison seems redundant because HR_ZONES_MOCK should never be null

    I understand that in the context of the specific build it's always an array and can never be null, but it can be null in release builds, so I don't feel like this error message is "fair".

  •  I think I found a bug. I get this error message:

    ERROR: fenix6: bin/optimized/group052-debug/source/source/MyField.mc:1154,20: Passing 'PolyType<Null or $.HrAlertView>' as parameter 1 of non-poly type '$.Toybox.WatchUi.DataFieldAlert'.

    It looks like the generated code is incorrect. I see the problem there, but I am not able to create a small file to reproduce it. It looks like it has to do with the huge inline functions nested in each other. Is there a way to send you a meaningful debug output?

    The problem is something like this:

    The problem is that in the generated code it checks for alertview == null instead of pmcr_alertView_0 == null. Interestingly enough in all the code I tried to create for POC it does check pmcr_alertView_0.
  • I understand that in the context of the specific build it's always an array and can never be null, but it can be null in release builds, so I don't feel like this error message is "fair".
    It looks like I have the same or similar issue with debug/release functions.
    Release function returns single object, while debug returns array of objects. I use this array as some kind of a test, where user of my release app has one specific value of a setting, while I use some tricks in debug builds for switching between all available setting values in simulator for testing purposes.
    import Toybox.Lang;
    
    (:release)
    function getDefaultSetting() as Number {
        return 0;
    }
    (:debug)
    function getDefaultSetting() as Array<Number> {
        return [0, 1];
    }
    
    (:release)
    function getSetting() as Number {
        var setting = getDefaultSetting();
        // ...
        return setting; // Expected $.getSetting to return Number but got Number or Array<Number>
    }
    (:debug)
    function getSetting() as Array<Number> {
        var settingsArray = getDefaultSetting();
        // ...
        return settingsArray; // Expected $.getSetting to return Array<Number> but got Number or Array<Number>
    }
    

    It came up earlier in this thread, that PMC ignores all annotations during analysis, so there were possible issues (until the fix was implemented) with code like this "(:debug) class A extends B {}" and "(:release) class B extends A {}".
    It is hard to say, how I would expect PMC to analyze such code. I guess, PMC could've analyzed debug/release code separately, as these branches are mutually exclusive. But I don't know, what to do for code with user-defined annotations.

    Interestingly enough in all the code I tried to create for POC it does check pmcr_alertView_0.

    You could try to incrementally remove large distant parts of your project gradually coming closer to this expression, while this bug still reproduces. I've successfully used such approach many times for narrowing down problems in PMC or Garmin's compiler. It is easier with PMC as IIRC it allowes you to generate optimized code for unbuildable project, e.g. with missing modules/classes/functions.