Disallow sealed overrides in structs

[lorcanmooney]

Fixes #11170. This reverts to the pre-Roslyn behaviour of generating an error for sealed overrides in a struct (that's assuming it's an acceptable breaking change).

[jmarolf]

@dotnet/roslyn-compiler @dotnet/roslyn-compat-council

[AnthonyDGreen]

What's the scenario motivating this change?

[gafter]

@AnthonyDGreen This is mainly a matter of complying with both the language specification and the previous native compiler behavior. If we're ever going to fix the missing diagnostic bug, fixing it sooner narrows the window in which customers could depend on it.

[lorcanmooney]

There's a more practical problem with the current behaviour in environments with mixed VS versions. If I use VS2015 and change a class to a struct without manually checking for overrides (how I came across this in the first place) I can happily build locally and send the changes on their way. Best case scenario, a VS2013 CI system picks up the change and rejects it. Worst case, there's a VS2015 CI system (or no validation) and now anyone with an older VS/toolset gets a broken build.

[AnthonyDGreen]

Ok.

[jaredpar]

👍

[gafter]

Lets keep this on hold for another day to see if anyone on @dotnet/roslyn-compat-council raises any objections.

[gafter]

I have verified that the native compiler rejects a sealed modifier on a method in a struct.

[agocke]

LGTM

@gafter We're running up against ask mode, so I'd say we should get this in sooner rather than later.

[gafter]

LGTM

[gafter]

@MattGertz @jaredpar Tagging you for ask mode.

[MattGertz]

Approved pending successful test completion.

[gafter]

@dotnet-bot test windows_debug_unit32_prtest please
@dotnet-bot test windows_debug_unit64_prtest please
@dotnet-bot test windows_eta_open_prtest please

[AlekseyTs]

LGTM