Mono ARM64 JIT inconsistent with sign-extension

[jkoritzinsky]

The DllImportGenerator test DllImportGenerator.IntegrationTests.BooleanTests.ValidateBoolIsMarshalledAsExpected fails on Mono ARM64 due to inconsistencies with sign extension.

This assert fails:

runtime/src/libraries/System.Runtime.InteropServices/tests/DllImportGenerator.Tests/BooleanTests.cs

Line 99 in 9362323

Assert.Equal(VARIANT_TRUE, NativeExportsNE.ReturnVariantBoolAsUInt(true));

because the zero/sign extension is inconsistent with how the UnmanagedCallersOnly return at

runtime/src/libraries/System.Runtime.InteropServices/tests/TestAssets/NativeExports/Booleans.cs

Line 19 in b201a16

return input;

is extended.

Runfo Tracking Issue: DllImportGenerator.IntegrationTests.BooleanTests.ValidateBoolIsMarshalledAsExpected

Build	Definition	Kind	Run Name

Build Result Summary

Day Hit Count	Week Hit Count	Month Hit Count
0	0	0

[agocke]

This is failing rolling builds -- if this was a recently introduced regression, can we revert and resubmit?

[jkoritzinsky]

This is a long standing bug that was discovered by merging in the DllImportGenerator.

We can add an [ActiveIssue] attribute to the failing test and point it to this issue.

[agocke]

Either disabling the issue or reverting the DllImport merge would be good. Whichever one we choose should be based on whether this issue would be considered blocking

[jkoritzinsky]

I think that given the scope of the merge, disabling the test is the correct approach.

[SamMonoRT]

At this point, I think disabling the test is fine. @fanyang-mono to follow up. We should also figure out if the test lanes were enabled as part of PR runs, why this wasn't caught prior to merging. (Totally understand if this is a rolling build only test run).

[fanyang-mono]

Moving to 9.0.0