[release/8.0-staging] Fix Int128 checked-convert to signed IntX

[github-actions]

Backport of #100342 to release/8.0-staging

/cc @tannergooding @skyoxZ

Customer Impact

• Customer reported: https://developercommunity.visualstudio.com/t/c--Checked-conversion-from-Int128-to-lo/10708678 and Overflows are ignored in some cases when checked-converting from Int128 to SignedInteger #99489
• Found internally

Checked operators are exposed so that developers can produce an exception on overflow. However, for some Int128 inputs the exception would not be thrown when the value was downcast to Int64 (long). This could result unexpected behavior as the value would be truncated instead. An example of this is which is expected to throw, but was not:

Int128 value = new Int128(0xFFFFFFFF_FFFFFFFF, 0x7FFFFFFF_FFFFFFFF);
return checked((long)value);

Regression

• Yes
• No

The Int128 type was introduced with this bug in .NET 7

Testing

Due to being two's complement its expected that all bits in upper match the most significant bit from lower. There was an edge case missed here for long that was being covered in other size conversions.

Explicit tests covering the impacted scenarios were added and the various checked conversions were made consistent with eachother.

Risk

Low, potentially Medium.

Int128 is a relatively new type to the ecosystem and checked conversions are not broadly used in the first place (in comparison to regular conversions).

However, while this fixes the underlying issue, it does cause an exception to be thrown when the scenario is encountered. This is the intended and expected behavior, but of course could surprise users after the patch goes out if they were not aware of the bug.

This case of code being changed to throw an exception, even though it is expected for such code to be already throwing, is what may be surprising and adds the risk that could potentially bump it into the medium risk category. I personally lean more towards "Low" given the newness of the type, that it only impacts a subset of values that match a particular bit pattern (other inputs were already throwing as expected), and that it requires users to be doing checked arithmetic which is known to be less common.

[dotnet-policy-service]

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

[tannergooding]

CC. @jeffhandley, @artl93. This has been fixed in .NET 9 for a bit now, but had a new issue opened up for it on VS Feedback and so should be considered for backport into .NET 8

[jeffhandley]

Looks good to me. I support backporting this to .NET 8 based on the customer reports and the fact that customers would expect exceptions here but we're returning the incorrect result instead. Please go ahead and request approval from Tactics, @tannergooding.