Big update to prettier-extension-monkeyc

9811827 said:

I'm curious, why barrel shouldn't be analyzed

I've always known that the optimizer can't run safely on a barrel project (without making some radical changes), and I guess I just assumed the same applied to the analyzer. But I actually found a simple fix for the incorrect warning this morning, so I left it analyzing the barrels.

9811827 said:

what I should expect to see now

I think you've found another bug.

The actual runtime path for BarrelTest.Strings.TestString is $.BarrelTest.Rez.Strings.TestString (but Garmin's compiler doesn't allow you to use that path in a resource file, for some reason - you have to use the short form).

Until recently, I didn't handle the short form at all, but in response to a bug report (one of yours I think), I fixed it so that references to @BarrelTest.Strings.TestString in resources belonging to the BarrelTest barrel get remapped correctly.

But thats too specific. It looks like I need to map @Foo.Strings.Bar to $.Foo.Rez.Strings.Bar if Foo is the name of any of the barrels associated with the project, regardless of where the reference occurs.

You can probably tell that I don't really use barrels; I've only got a couple of garmin projects that use barrels, and a couple of open source ones, and some synthetic projects I've made for tests - and evidently none of them exercise this...

I've pushed a fix for this one, and the earlier one to monkeyc-optimizer if you want to try it.

While I was working on the first issue, I realized that visit refs and defs needs an update to deal with multi-project workspaces. If there are multiple apps in the workspace that use the same Barrel, then Find References will only find the references in the Barrel (if the barrel is in the workspace), or the references in the barrel and one of the apps (if the barrel isn't in the workspace).

Ignoring barrel projects would help with that, but wouldn't fix it entirely, so I need to fix that so that it finds every project that refers to the current file, and then finds all the refs across all those projects.

v2.0.99 is out

Fixes issues with references to Barrel resources, and makes fixes refs and defs to search across projects (eg if the symbol you click on is in a Barrel project, and there are two other projects that use the barrel in the workspace, it will now find all the refs from all three projects). 

There's a little cosmetic issue while reporting about missing symbols, that I started to see in 2.0.99 (probably, due to proper barrels analysis).

With

const LONG_NOT_EXISTING_RESOURCE = Rez.Strings.LongNotExistingStringResource1234567890123456789012345678901234567890;

anywhere in the project I see a bit ugly error message

Undefined symbol Rez.Strings
    .LongNotExistingStringResource1234567890123456789012345678901234567890

that is multilined, while all others aren't.

The same result is for running analysis from command line:

ERROR: Undefined symbol Rez.Strings
    .LongNotExistingStringResource1234567890123456789012345678901234567890 at ...

I expect this resource to be missing at this stage, and it is not a big deal, but I think it's still worth reporting.

I have a generic formatAst that converts ast nodes to strings using prettier, and I used that for a lot of error messages. I had noticed similar issues for certain kinds of nodes in the past, and added a special formatAstLongLines that overrides prettier's line length. But I only used it in a few places where I'd noticed problems. I just went through every use of formatAst, and every one except for printing the optimized source is for error messages; so I switched them all to the long lines version...

It seems, "Go to definition" sometimes doesn't work for typedefs and in typedefs themselves:

import Toybox.Lang;

class TestClass {
    typedef Type as Number;

    typedef AnotherType as Type or TestEnum;

    enum TestEnum {
        VALUE,
    }

    function initialize(value as Type, anotherValue as AnotherType) {}
}

"Find references" works for "Type", "AnotherType" and "TestEnum".

This was introduced in 2.0.97, when I made it look for overriding definitions too. That broke lookup of types declared in classes (because I wasn't thinking). The fix will be in the next release.

... and while writing tests I discovered that I was not allowing renames for typedefs in classes, which was pointless. So I've fixed that too.

Sorry for asking such questions here, but you may be one of the few people outside the CIQ team, who can answer them.

Could you, please, also explain, why there is no warning about undefined "AnotherClass" in "ClassThatExtendsClassFromModule", and the code compiles with strict checking, but there is "Cannot find symbol ':AnotherClass' on type 'self'" for "ClassThatDoesntExtendClassFromModule" (and PMC knows this too and gives the same warning as a result of live analysis)?

module SomeModule {
    class ClassFromModule {
    }
    class AnotherClass {
        function func() as Void {}
    }
}

class ClassThatExtendsClassFromModule extends SomeModule.ClassFromModule {
    function initialize() {
        (new AnotherClass()).func();
    }
}

class ClassThatDoesntExtendClassFromModule {
    function initialize() {
        (new AnotherClass()).func();
    }
}

Does extending class from the module also adds implicit import of all its classes, functions and modules within class' scope?