Disable nullable comparison optimization for decimals #73536
Conversation
dotnet-issue-labeler
bot
added
Area-Compilers
untriaged
|
Have we done similar change (the regression) for VB? |
| { | ||
| System.Console.Write(M(x) ? 1 : 0); | ||
| } | ||
| static bool M(decimal? x) => x == 0.0m; |
There was a problem hiding this comment.
Consider testing x == 0.00m and 0.00m == x since the reported issue uses 0.00m.
There was a problem hiding this comment.
Let's also test x != <constant> and <constant> != x.
| C.Run(0.0m); | ||
| C.Run(1m); | ||
| C.Run(2m); | ||
| C.Run(null); |
| or ConstantValueTypeDiscriminator.NUInt | ||
| or ConstantValueTypeDiscriminator.SByte | ||
| or ConstantValueTypeDiscriminator.Single | ||
| or ConstantValueTypeDiscriminator.String |
| return constantValue is | ||
| { | ||
| IsDefaultValue: false, | ||
| Discriminator: ConstantValueTypeDiscriminator.Boolean |
There was a problem hiding this comment.
Thanks. Looks like integers smaller than 32 bits are not optimized because they use Int32's equality operator, so I will remove them from the list.
No, the optimization hasn't been implemented for VB. |
| { | ||
| System.Console.Write(M(x) ? 1 : 0); | ||
| } | ||
| static bool M(short? x) => x == 1; |
There was a problem hiding this comment.
That results in longer IL, you can see that in SharpLab. Same for other less-than-32bit ints. Doesn't seem to have any effect on the optimization as it's currently (or was) implemented. The cast creates a more complicated bound tree
| { | ||
| System.Console.Write(M(x) ? 1 : 0); | ||
| } | ||
| static bool M(ushort? x) => x == 1; |
| { | ||
| System.Console.Write(M(x) ? 1 : 0); | ||
| } | ||
| static bool M(sbyte? x) => x == 1; |
|
Please cherry pick to release/dev17.10 after merge |
Fixes #73510, a regression introduced by #68069.