nullable switch no longer switches from warnings to errors

[astrowalker]

In a way, a follow up to #41605

Version Used:

VS 2019 Pro Version 16.8.1

Steps to Reproduce:

1. Create Netstandard 2.1 project for example

2. Enable Nullable

3. Add "nullable" to WarningsAsErrors section, so with default values already present it shoudl be

   <WarningsAsErrors>nullable;NU1605</WarningsAsErrors>

Expected Behavior:

Nullable errors.

Actual Behavior:

Nullable warnings.

Notes:

• when I use explicit values "CS8600;CS8602;CS8603;CS8613;CS8601;CS8625;CS8604;CS8618" instead of "nullable" it works (i.e. I got errors, not warnings)
• not part of this report, but hard not to mention it -- when entering project properties in VS, there is "Nullable" combo with "Enable" value which produces warnings and "Warnings" value which produces... warnings. What is the point of it, and wouldn't it be more beneficial to have simple to understand "Disable|Warnings|Errors|Annotations" selection? Maybe it was supposed to work like this and the bug lies there?

[RikkiGibson]

I tried to reproduce and found that the command line build actually gave error diagnostics, but we still got warning diagnostics in the IDE. This might be an instance of #38371

[RikkiGibson]

there is "Nullable" combo with "Enable" value which produces warnings and "Warnings" value which produces... warnings. What is the point of it, and wouldn't it be more beneficial to have simple to understand "Disable|Warnings|Errors|Annotations" selection?

It does sound odd that the combo box doesn't just enumerate the options which are available for the <Nullable> property. I took a look in my VS 16.8.1 project properties page and saw this:

So I don't know what caused your combo box to be missing the "annotations" value.

Also, this doc should clear up what "Enable" means versus "Warnings".

[jaredpar]

Moving to IDE as this work sas expected in command line builds.

[astrowalker]

@RikkiGibson , I am not saying my combo box is missing Annotations, I am saying my combo box (as yours) has two entries (among others) -- Enable and Warnings that behave the same, they result in Warnings. In order to trigger errors (now not working) you have to go somewhere else, and switch transition from warnings to errors.

Just for the record, this was just a comment. The main point is there is problem with triggering errors.

[mavasani]

The core issue here is that the logic to map special warnaserror value "nullable" to actual nullable IDs is inside the C# command line parser, which will not be part of compilation options for all hosts except command line build:

roslyn/src/Compilers/CSharp/Portable/CommandLine/CSharpCommandLineParser.cs

Lines 1987 to 1996 in 823039e

	if (string.Equals(id, "nullable", StringComparison.OrdinalIgnoreCase))
	{
	foreach (var errorCode in ErrorFacts.NullableWarnings)
	{
	yield return errorCode;
	}
	yield return CSharp.MessageProvider.Instance.GetIdForErrorCode((int)ErrorCode.WRN_MissingNonNullTypesContextForAnnotation);
	yield return CSharp.MessageProvider.Instance.GetIdForErrorCode((int)ErrorCode.WRN_MissingNonNullTypesContextForAnnotationInGeneratedCode);
	}

This issue can be fixed in couple of possible ways:

1. Compiler exposes a public API that maps "nullable" keyword to set of CS diagnostic IDs so other hosts can replicate this functionality.
2. The above logic to convert "nullable" to CS diagnostic IDs is moved to CompilationOptions constructors which set CompilationOptions.SpecificDiagnosticOptions.

Latter seems more preferable as it will implicitly fix all diagnostic hosts - though, I'll let the compiler team decide. Moving the issue back to Area-Compilers.

[RikkiGibson]

thanks for the detailed analysis!

[JoeRobich]

O# is handling this by maintaining their own mapping - OmniSharp/omnisharp-roslyn#2406 - which is not ideal.