Nullable decimal comparison bug in dotnet 8.0.5 (SDK 8.0.300)

[Quintinon]

Description

There is a change in how a null valued decimal? behaves in 8.0.5 compared to previous version of the sdk/runtime.
I'm seeing the result of nullDecimalVariable == 0.00m to be equal to true in 8.0.5 (SDK 8.0.300) but was false in previous versions.

Reproduction Steps

I created a simple new console application using dotnet new console and pasted the following code into it.

decimal? v = 0.00m;
Console.WriteLine(v == decimal.Zero); // True in both 8.0.205 and 8.0.300
v = null;
Console.WriteLine(v == decimal.Zero); // False in both 8.0.205 and 8.0.300
Console.WriteLine(v == 0.00m); // False in 8.0.205 and true in 8.0.300

I also added a global.json file to control which version of the dotnet SDK it was running against. I swapped between 8.0.205 and 8.0.300 which are the two versions of 8 I have installed. 8.0.205 was installed with visual studio, and I manually installed 8.0.300 via the SDK download to reproduce this bug.

I was only able to reproduce this using the command line dotnet run. Running in visual studio did not reproduce this issue. It is not only occurring on my machine. We had a test failure with the same root cause as this minimal repo on our two different dedicated build machines.

Test.zip

Expected behavior

I expected null == 0.00m to return false as shown in 8.0.205

Actual behavior

null == 0.00m is returning true as shown in 8.0.300

Regression?

Yes. I tried on the previous SDK version of 8.0.205 and it works.

Known Workarounds

No response

Configuration

Dotnet 8.0.5 (SDK 8.0.300)
System Information:
Edition Windows 11 Pro
Version 23H2
Installed on ‎4/‎15/‎2024
OS build 22631.3447
Experience Windows Feature Experience Pack 1000.22688.1000.0

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

The comparison operator of nullables are synthesized by compiler:

https://sharplab.io/#v2:D4AQTAjAsAUCDMACciDCiDetE+UkALIgLIAUAlNrljLnYgCYCmAxgJYC2AhgDYD8iAG6IAvIgAMAOnHiOAbir1kEAJylhIsc3bcekgFpMATgHtycxAHpLiACpGArk0RsAdogBGJgC4ALRAAc0pJg4gCsiFyuDIHB8DKK9BqIrg48PAq0SspqGlqsnLwGxmYW1ogAYrwAzs5unj7+QVKhEVExzZLx4ol0IKrqomJSMhzmVjZVPLUu7p2tkdGI3o51c3EJWTgAvrDbQA==

The difference of SDK version also suggests this. SDK 8.0.205 and 8.0.300 shares the same runtime version of 8.0.5, but different compiler versions. So this is probably a C# compiler bug for https://github.com/dotnet/roslyn.

[huoyaoyuan]

Switching to main in SharpLab, the HasValue call disappears in decompilation of the third invocation.

[Quintinon]

Do I need to repost this issue over to the roslyn repo?

[333fred]

Do I need to repost this issue over to the roslyn repo?

No, we're addressing it directly now. Thanks for the report!

[irmen]

Running in visual studio did not reproduce this issue

For us it did, but only after we updated to the most recent version (17.10.0). (that also installed sdk 8.0.300)

[cremor]

Cross-posting from #73572 (comment) so that users who don't follow that PR also know the current situation of the fix:

But if you have SDK 8.0.3xx (and build using dotnet build command for example), the bug is still there; should be fixed in 8.0.303

TBH I find this quite irritating. The bug was so severe that it:

• Made it in the known issues list of Visual Studio
• Was fixed in just 2 days.
• Was released with a new Visual Studio update in just 8 days.

But still, now 6 weeks later, there is no SDK release with the fix. In my opinion, the SDK is way more important than VS because the SDK is what actually compiles our release software on build agents.

Update: The fix is part of SDK 8.0.303. See #73572 (comment)