Description

Jaykul

opened on Jul 23, 2020

Issue body actions

If I have this, for instance, in a file in classes:

using namespace System.Collections.Generic

class Resolver {
    [Dictionary[string, PSObject]]$Cache = [Dictionary[string, PSObject]]::new()
}

Then if we get the error because the using statement isn't the first thing in the new module, we will always(?) also get a TypeNotFound error about the Dictionary, which will prevent the using statement from being removed.

I thought we already fixed this?

Activity

1. gaelcolas commented on Aug 13, 2020

   

   gaelcolas

   on Aug 13, 2020

   Contributor

   More actions

   This one wasn't fixed, but I've noticed this and a few other issues.
   In short, I think we should always try to move using statements if we find UsingMustBeAtStartOfScript error, because if the module is invalid, it sould be caught just after being built.

   There are Parsing errors that PowerShell don't mind, and still happily build the modules.
   There are other types of errors that we'll always have during parsing, like some type not found, because the type is not loaded (maybe in module manifest, or in code).

   That happens as well with class attributes, like the YamlDotNet [YamlIgnore()] attribute...

   All in all, now I suggest to just move the using statements anyway as soon as we find a UsingMustBeAtStartOfScript.

   If anything goes wrong after that, it may or may not be our fault, but for sure if the using is not at the right place it will most likely fail.

   What do you think?
2. Jaykul commented on Aug 13, 2020

   

   Jaykul

   on Aug 13, 2020

   MemberAuthor

   More actions

   I guess I can live with that.

   Honestly, the reason we're checking is that if the module is busted, we don't want to make it worse (or more confusing to troubleshoot) -- but as you say, right now it means some modules won't build at all. I'll have to think about adding a -IgnoreUsingStatements switch so people can disable it if it's causing them problems.

   Reacted by gaelcolas
3. gaelcolas

   added a commit that references this issue on Aug 18, 2020

   fix PoshCode#96 by moving statements even if parsing errors exists

   This issue will close once commit 7d463d3 is merged into the 'main' branch.

   7d463d3
4. Jaykul

   added a commit that references this issue on Aug 28, 2020

   fix PoshCode#96 by moving statements even if parsing errors exists

   This issue will close once commit ed56dca is merged into the 'main' branch.

   ed56dca
5. Jaykul

   closed this as completedin ed56dcaon Aug 29, 2020
6. Jaykul

   added 2 commits that reference this issue on Aug 29, 2020

   Fix #96 move using statements even if there are parse errors afteward

   This issue will close once commit ee24e1c is merged into the 'main' branch.

   ee24e1c

   Fix #96 move using statements even if there are parse errors afteward

   This issue will close once commit acd9976 is merged into the 'main' branch.

   acd9976

Issue actions