Stray semicolon above namespace keyword causes warning CS7022 and unexpected exit

[OoLunar]

Description

Expected behavior:
Either compiler error to be thrown or for everything to run as expected without a sudden exit.

Actual behavior:
Having a stray semicolon above the namespace keyword causes CS7022. A reproducable example is below:

using System.Linq;
using System.Reflection;
using System.Text;
using System.Threading.Tasks;
; // This will cause CS7022

namespace Tomoe.Commands.Public {

This can be placed in any C# file, and the runtime warning will occur, causing the program to suddenly exit with code 0. Opening up the debugger, it seems it exits right after System.Runtime.dll loads. It seems several people over on this StackOverflow Answer have also been having this issue.

Configuration

.NET version: 5.0.202
OS: Windows 10 and Ubuntu 20.04
Arch: x64
Specific to configuration: Untested.

Regression?

Haven't thoroughly tested. On .netcore3.1 in Visual Studio, a syntax error is thrown with the following message: Feature "top-level statements" is not available in C# 8. Please use language version 9 or higher

Other information

I start the program, I get the warning, then it suddenly exits with code 0. Yes, the same behaviour happens when I'm in Gnome Terminal (Ubuntu) or Windows Terminal/Powershell (Windows 10)

Simple Solution

Remove stray semicolons. No stack traces will be thrown. A great way to teach fellow peers to always review PR's instead of accepting them blindly.

[mairaw]

@jaredpar can you help route this? Is this something we could catch at compile time?

[jaredpar]

Thanks for taking the time to file this feedback issue. Unfortunately this is not a bug. The language is operating as intended here. The top level semi-colon here is a valid statement in C# and hence is correctly interpreted as such. The warning here is alerting the user that the typical Main method is being ignored because of the presence of top level statements.

This is functioning how the language team intended here.

[OoLunar]

Pardon me, but you're telling me that it's intentional that the program will exit? These top level semicolons can be littered across several files, and the warning will only be thrown at the file with the Main method. This can lead to several hours wasted because the top level semicolon was in file B, but the main method and warning was in file A

[jaredpar]

Pardon me, but you're telling me that it's intentional that the program will exit?

It's intentional that the compiler will execute top level statements when defined by the customer. In the case that the customer defines one of the no-op statements (empty statement, uninitialized decl, etc ...) then yes the program will exit after completing them with no visible effect. This is true if you put the same statements in traditional Main methods.

These top level semicolons can be littered across several files, and the warning will only be thrown at the file with the Main method.

Top level statements can only occur in a single file. Using them in multiple files will produce an error.

This can lead to several hours wasted because the top level semicolon was in file B, but the main method and warning was in file A

I agree that there are cases where this can be subtle to detect. At the same time the it's not desirable for the compiler to emit warnings here. Consider why would the compiler emit a warning here but not emit a warning with the Main method had a single statement that was a semi-colon?

static void Main() { 
    ;
}

This is just as wrong in that it immediately exits yet the compiler doesn't give a diagnostic. There are also a host of other statements for which there is an immediate exit (unused decls for example). The principal here is that we treat top level statements essentially as if they were typed in the Main method itself and give equivalent diagnostics for them.

[OoLunar]

Ah, that makes a lot more sense now. Thank you for the very thorough explanation.

[SJFriedl]

This feels like it violates the Principle of Least Surprise, and that treating

using My.Library;; // note two semicolons

the same as a customer intended to create an empty null block is going to have a lot of people - including those in this thread - just burn a bunch of time.

It's too bad that this special case - a single stray semicolon at the top level - can't trigger a slightly more specific diagnostic, because that single semicolon, though legal in the language, is going to be a typo far more often than it will be intentional. Of course, resolvable by Bingling, but it doesn't seem like it should be necessary.

"The best tech support is that which is not needed" - me

[jcouv]

Re-opening as LDM decided to make it an error if all top-level statements are empty.