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)