Report CS8802 on every file with top-level statements

[64bitsDuck]

Fixes #83691

Summary

When multiple compilation units have top-level statements, the CS8802 error
message previously only reported the offending file without indicating which
file was already accepted as the entry point. This made it harder to locate
the conflict, especially in larger projects.

This change reports the diagnostic on every compilation unit that has top-level
statements, so clicking each entry in the error list takes you straight to a file
you have to edit.

Changes

• SourceMemberContainerSymbol.cs: emit CS8802 for every declaration with
  top-level statements when more than one exists, instead of skipping the first
• TopLevelStatementsTests.cs: existing tests now expect the additional
  diagnostic on the first file
• RemoveUnusedMembersTests.cs: same, for the two analyzer tests that compile
  multiple files with top-level statements
• Simplified an operation tree assertion in Simple_06_02 that was conditional
  on which tree was reported; both are now always invalid
• Added MultipleTopLevelStatements_ReportedInEveryFile and
  MultipleTopLevelStatements_SourceGeneratedFile

Microsoft Reviewers: Open in CodeFlow

[64bitsDuck]

@dotnet-policy-service agree

[333fred]

Overall this looks like an acceptable approach, but I do want to understand what the UX looks like for source generated files.

[333fred]

Think we should probably test what this looks like with source generated entry point files.

[64bitsDuck]

Good point, from what I understand source generated files are susceptible to having a null filepath, should we fall back to a generic label like generated, or omit the path entirely?

[333fred]

Sorry, missed that you asked a question and it fell off my radar on vacation. I wouldn't do anything special, I just wanted to see what it looked like and document in a test.

[RikkiGibson]

Perhaps when multiple files have top-level statements, then we should report a diagnostic in all such files, instead of reporting for "all the files after the first one". That will make it so clicking each diagnostic in the error list will just take you to the right place, rather than having to look at the filename in the message and navigate to it, in order to decide which top-level statements you intended to keep.

[64bitsDuck]

@RikkiGibson please excuse the late response, some comments escaped my attention.
I'd like to be sure of what to modify before I make any change:
The idea would be to also emit CS8802 on the first file (the one accepted as entry point), so that all conflicting files show up in the error list? If we do this, should we keep the file name in the message or is navigating via the error list enough?
Thanks

[RikkiGibson]

should we keep the file name in the message or is navigating via the error list enough?

No, if you report an error on every file which had top-level statements, then, I would just restore the original message which lacks the file name.

[64bitsDuck]

I would just restore the original message which lacks the file name.

That makes sense, so we'd emit CS8802 on every file including the first one right? It does seem like a more user friendly approach. Once that's confirmed I'll gladly implement this version of the fix

[RikkiGibson]

That makes sense, so we'd emit CS8802 on every file including the first one right? It does seem like a more user friendly approach. Once that's confirmed I'll gladly implement this version of the fix

Yes, please do.

[333fred]

Thanks @64bitsDuck! Apologies this took so long to review.