Roslyn: Compiler errors should have a better error message

[mikadumont]

Here are a few error messages that were suggested as unclear:

CS0029 — Cannot implicitly convert X to Y
CS0103 — X does not exist in the current context
CS0161 — Not all code paths return a value
CS0165 — Use of unassigned local variable
CS1002 — Semicolon expected
CS1513 — } expected (missing closing scope)
CS1525 — Invalid expression term. Specifically when using == instead of = for assignment (e.g. int i == 4)
CS7036 — No argument given that corresponds to the required formal parameter (incorrect method call)

Feel free to comment on this issue with other error messages that aren't clear today.

[PathogenDavid]

Feel free to comment on this issue with other error messages that aren't clear today.

• CS8802: Only one compilation unit can have top-level statements.
• CS8804: Cannot specify /main if there is a compilation unit with top-level statements.

I know what these mean, but I think the term "compilation unit" is compiler nerd language that beginners would not understand, and it's not something they can easily look up. More info here: https://github.com/dotnet/roslyn/issues/45926

[CyrusNajmabadi]

I am curious what would be suggestoins as better error messages. For example:

CS0103 — X does not exist in the current context

Not sure what else we can say there. user wrote 'X' here.... but we couldn't find an X that exists here...

Note that i strongly do not want us to have diagnositc messages that are overly verbose or require wrapping or multiple lines to explain in the error list. And, for all of these errors, we do have hyperlinks to large explanation pages helping give full context on what these mean, when they happen, and how one can potentially fix them.

[svick]

@CyrusNajmabadi In case it looks like a typo, the error message could suggest the correct spelling. In case X exists in a nearby scope (like in the example in the documentation), the message could contain a short sentence saying that the scope of that variable does not extend here. (In this case, it would be great to somehow point to that variable, but I don't think there's a good way to do that.)

Such heuristics won't always guess the actual cause of the error, but I think they can be correct often enough to be useful.