Changing warning CS8002 to an error still results in binary being outputted despite error

[jasonmalinowski]

Version Used: 4.11.0-2.24304.1 (e68227e)

Steps to Reproduce:

1. Clone https://github.com/jasonmalinowski/StrongNameSigningProblem
2. Run dotnet build. See it errors out.
3. Run dotnet build again. Observe it succeeds.

Expected Behavior: Build is stable.

Actual Behavior: It's not stable.

I debugged into this a bit and here's what's happening: CS8002 is normally a warning. If it's changed to be an error the compiler emits the error, but still writes out the assembly for the build output. Hence the next time (or two) you build. The build will succeeded since MSBuild considers the CoreCompile target to be up to date.

One thing I noticed is this the diagnostic is only emitted if you actually use a type from the library -- I'm guessing what's happening here is during emit we do a final walk through the list of assemblies used, and at that point we're flagging this as an error. But that never aborts the build anymore since it wasn't expected to have an error like this so late.

[jaredpar]

This is likely just a side effect of how warning to error promotion works. Essentially, warnings raised during emit don't stop it as their a warning. The later error promotion isn't considering this case and it results in a binary on disk. Suspect this will happen for any emit warning, not just strong naming.

Backlog for now until we see more evidence of it being a problem.