Incorrect Diagnostic given sometimes when naming type

[u9g]

As seen in the screenshot, the compiler gives the diagnostic that "names" should start with lowercase letters despite this being a type name, which should give the second diagnostic shown.

[lpil]

Oops. Thank you!

[Acepie]

Looks like the difference between the two is that the first one errors earlier as a lexer error before even getting to the parser for the compiler to figure out if it expected a value name or a type name. We could either change the error message to be applicable to either or we could somehow switch the lexer to accept this and move the error forward to the parser.

FWIW you can also get the opposite error (expected a value name but user started with an uppercase and gets a lex error) for the same reason as shown in the screenshot below.

Changing the error message is definitely the easier/less error prone option since I think the alternative would probably require lexing both as a single token type and disambiguating in the parser but not sure if the user experience would actually be better (i.e would we be better off just having a single bad name message that mentions both the type and value constraints)

[Acepie]

Alternatively instead of immediately returning a lex error for these cases we make a new token type for a generic bad name and continue lexing so that the parser can decide which one it wanted

Edit: looking at this more in the code there are a lot of places where it actually is ambiguous since constructor variants are valid value UpNames so this would probably just shift the confusion forward/to more places

[lpil]

We're talking about relaxing the parsing of lowercase names and turning them into an error in analysis in order to enable the formatter to auto-correct function names. That would enable us to give error messages with more context here too if we decide to do that.

#2978

[Arian94]

The thing I can think of is that in this language the naming convention is determined by its previous token (let, type etc.) so THIS should be the controlling factor in the consume_normal() implementation but one can see that the name itself is being examined in order to give proper corrections. That's the real issue and a refactor might be needed.