roslyn: WarningsAsErrors for CS8602 is not returning an error
Version Used: Visual Studio 2019 16.2.3 .NET Core: 3.0.0-preview8-28405-07
Steps to Reproduce:
For CS8602 I am not getting the expected errors when I add this code in the WarningsAsErrors section.
- Modify the csproj as:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
+ <Nullable>enable</Nullable>
+ <WarningsAsErrors>CS8602</WarningsAsErrors>
</PropertyGroup>
</Project>
- My sample application code is:
private static void PosibleDereferenceNullableReferenceTypes()
{
string data = null;
Console.WriteLine(data.Length);
}
Expected Behavior: An error when we build the project. Error CS8602 Dereference of a possibly null reference.
Note: When I put the codes CS8600, CS8603 or CS8604 into the WarningsAsErrors section, I receive the expected error messages in compilation time.
Actual Behavior: Warning CS8602 Dereference of a possibly null reference.
Updated information about this issue and its behavior:
If I write into the csproj: <WarningsAsErrors>CS8600;CS8602</WarningsAsErrors> I get the error messages for CS8600 (as expected) and for CS8602
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 1
- Comments: 15 (12 by maintainers)
As far as I am aware, this is a project system bug, and can’t be fixed within Roslyn. /cc @davkean
Basically, it seems like for some values of WarningsAsErrors, the project system sends us a command line with
... /warnAsError- ... /warnAsError+:CS0105 ...
. For other values it sends us a command line like... /warnAsError+:CS8602 ... /warnAsError- ...
. The latter case is where the bug happens-- warnAsError- wins and we don’t get the right behavior in the IDE.Yes I think that’s a good idea. Go ahead and link to this issue from that one.
Should I create an issue in that repo then to track? I’m happy to do any troubleshooting etc. that might help figure out where the bug might be.
https://github.com/dotnet/roslyn/issues/52407 (issue with
WarningsAsErrors=nullable
setting) indeed looks to be caused by the same random ordering problem 😕