Fix FileNotFoundException in NativeAOT test

[Copilot]

• Diagnose: Runtime_101046.csproj and Runtime_101046.ilproj shared the same project name, so they shared OutputPath/IntermediateOutputPath and the generated .cmd/.sh wrapper and overwrote each other's outputs. After Enable out-of-process tests for CoreCLR browser WASM #131110 added a TestLibraryProjectReference + [ActiveIssue(typeof(PlatformDetection), ...)] to the C# variant only, NativeAOT builds could ILC-compile the C# assembly without TestLibrary in its reference set, so __GeneratedMainWrapper.Main() became a throwing body (FileNotFoundException: Could not find file 'TestLibrary').
• Rename the C# variant to Runtime_101046_1 (project, source file, test class) so the two tests no longer share output/intermediate directories
• Replace the TestLibrary-based ActiveIssue gate with the CLRTestTargetUnsupported project gate used by sibling native-asset tests
• Apply the same native-test-asset gate to the IL variant, which now actually runs
• Gate the IL variant off x64 Unix: once it really runs it fails there (JIT passes the un-normalized uint16, the clang-built callee assumes normalization) — needs a JIT-team decision, noted for follow-up
• Validate: built clr+libs and the test tree, ran both wrappers on linux-x64 (Runtime_101046_1 passes; IL variant excluded on x64 Unix)

• Fixes[ci-scan] Test failure: JIT/Regression/JitBlue/Runtime_101046 NativeAOT FileNotFoundException 'TestLibrary' #131997

[Copilot]

Copilot wasn't able to review any files in this pull request.

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046.ilproj:11

• The x64 Unix gating comment links to issue #131997, but that issue tracks a NativeAOT FileNotFoundException (TestLibrary) rather than the uint16 pinvoke normalization behavior described here. This makes the gate hard to audit later; please remove the incorrect link or replace it with the correct tracking issue for the normalization mismatch.

 <!-- The JIT only normalizes small primitive pinvoke arguments where the ABI requires it, but the
clang-compiled callee assumes normalization on x64 Unix: https://github.com/dotnet/runtime/issues/131997 -->
<CLRTestTargetUnsupported Condition="'$(TargetArchitecture)' == 'x64' and '$(TargetsUnix)' == 'true'">true</CLRTestTargetUnsupported>

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

[jakobbotsch]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?
Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

Yes, it is. See llvm/llvm-project#43573

[jakobbotsch]

I see -- well, that's unfortunate.

The original issue is #101046 and it was never based on a customer report, just from my reading of the ABIs. Normally you cannot hit that from C# code because in C# code you have to insert explicit casts.
I think it should be ok to disable the test for the target with a reference to the LLVM bug.

[AndyAyersMS]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

[Copilot]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

Updated in 7ec8799. The x64 Unix exclusion comment in Runtime_101046.ilproj now explicitly states this is due to LLVM’s non-standard ABI handling and links to llvm/llvm-project#43573.

[AndyAyersMS]

@jakobbotsch can you re-review

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046_1.cs:11

• The file header still says this is the reference source for the .il file, but after renaming the C# test to Runtime_101046_1 the corresponding IL variant is Runtime_101046.il (and its class/assembly name remains Runtime_101046). Please update the comment so it stays accurate and doesn’t imply the class names match.

[AndyAyersMS]

/ba-g unrelated failures

[Copilot]

• Diagnose: Runtime_101046.csproj and Runtime_101046.ilproj shared the same project name, so they shared OutputPath/IntermediateOutputPath and the generated .cmd/.sh wrapper and overwrote each other's outputs. After Enable out-of-process tests for CoreCLR browser WASM #131110 added a TestLibraryProjectReference + [ActiveIssue(typeof(PlatformDetection), ...)] to the C# variant only, NativeAOT builds could ILC-compile the C# assembly without TestLibrary in its reference set, so __GeneratedMainWrapper.Main() became a throwing body (FileNotFoundException: Could not find file 'TestLibrary').
• Rename the C# variant to Runtime_101046_1 (project, source file, test class) so the two tests no longer share output/intermediate directories
• Replace the TestLibrary-based ActiveIssue gate with the CLRTestTargetUnsupported project gate used by sibling native-asset tests
• Apply the same native-test-asset gate to the IL variant, which now actually runs
• Gate the IL variant off x64 Unix: once it really runs it fails there (JIT passes the un-normalized uint16, the clang-built callee assumes normalization) — needs a JIT-team decision, noted for follow-up
• Validate: built clr+libs and the test tree, ran both wrappers on linux-x64 (Runtime_101046_1 passes; IL variant excluded on x64 Unix)

• Fixes[ci-scan] Test failure: JIT/Regression/JitBlue/Runtime_101046 NativeAOT FileNotFoundException 'TestLibrary' #131997

[Copilot]

Copilot wasn't able to review any files in this pull request.

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046.ilproj:11

• The x64 Unix gating comment links to issue #131997, but that issue tracks a NativeAOT FileNotFoundException (TestLibrary) rather than the uint16 pinvoke normalization behavior described here. This makes the gate hard to audit later; please remove the incorrect link or replace it with the correct tracking issue for the normalization mismatch.

 <!-- The JIT only normalizes small primitive pinvoke arguments where the ABI requires it, but the
clang-compiled callee assumes normalization on x64 Unix: https://github.com/dotnet/runtime/issues/131997 -->
<CLRTestTargetUnsupported Condition="'$(TargetArchitecture)' == 'x64' and '$(TargetsUnix)' == 'true'">true</CLRTestTargetUnsupported>

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

[jakobbotsch]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?
Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

Yes, it is. See llvm/llvm-project#43573

[jakobbotsch]

I see -- well, that's unfortunate.

The original issue is #101046 and it was never based on a customer report, just from my reading of the ABIs. Normally you cannot hit that from C# code because in C# code you have to insert explicit casts.
I think it should be ok to disable the test for the target with a reference to the LLVM bug.

[AndyAyersMS]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

[Copilot]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

Updated in 7ec8799. The x64 Unix exclusion comment in Runtime_101046.ilproj now explicitly states this is due to LLVM’s non-standard ABI handling and links to llvm/llvm-project#43573.

[AndyAyersMS]

@jakobbotsch can you re-review

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046_1.cs:11

• The file header still says this is the reference source for the .il file, but after renaming the C# test to Runtime_101046_1 the corresponding IL variant is Runtime_101046.il (and its class/assembly name remains Runtime_101046). Please update the comment so it stays accurate and doesn’t imply the class names match.

[AndyAyersMS]

/ba-g unrelated failures

[Copilot]

• Diagnose: Runtime_101046.csproj and Runtime_101046.ilproj shared the same project name, so they shared OutputPath/IntermediateOutputPath and the generated .cmd/.sh wrapper and overwrote each other's outputs. After Enable out-of-process tests for CoreCLR browser WASM #131110 added a TestLibraryProjectReference + [ActiveIssue(typeof(PlatformDetection), ...)] to the C# variant only, NativeAOT builds could ILC-compile the C# assembly without TestLibrary in its reference set, so __GeneratedMainWrapper.Main() became a throwing body (FileNotFoundException: Could not find file 'TestLibrary').
• Rename the C# variant to Runtime_101046_1 (project, source file, test class) so the two tests no longer share output/intermediate directories
• Replace the TestLibrary-based ActiveIssue gate with the CLRTestTargetUnsupported project gate used by sibling native-asset tests
• Apply the same native-test-asset gate to the IL variant, which now actually runs
• Gate the IL variant off x64 Unix: once it really runs it fails there (JIT passes the un-normalized uint16, the clang-built callee assumes normalization) — needs a JIT-team decision, noted for follow-up
• Validate: built clr+libs and the test tree, ran both wrappers on linux-x64 (Runtime_101046_1 passes; IL variant excluded on x64 Unix)

• Fixes[ci-scan] Test failure: JIT/Regression/JitBlue/Runtime_101046 NativeAOT FileNotFoundException 'TestLibrary' #131997

[Copilot]

Copilot wasn't able to review any files in this pull request.

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046.ilproj:11

• The x64 Unix gating comment links to issue #131997, but that issue tracks a NativeAOT FileNotFoundException (TestLibrary) rather than the uint16 pinvoke normalization behavior described here. This makes the gate hard to audit later; please remove the incorrect link or replace it with the correct tracking issue for the normalization mismatch.

 <!-- The JIT only normalizes small primitive pinvoke arguments where the ABI requires it, but the
clang-compiled callee assumes normalization on x64 Unix: https://github.com/dotnet/runtime/issues/131997 -->
<CLRTestTargetUnsupported Condition="'$(TargetArchitecture)' == 'x64' and '$(TargetsUnix)' == 'true'">true</CLRTestTargetUnsupported>

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

[jakobbotsch]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?
Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

Yes, it is. See llvm/llvm-project#43573

[jakobbotsch]

I see -- well, that's unfortunate.

The original issue is #101046 and it was never based on a customer report, just from my reading of the ABIs. Normally you cannot hit that from C# code because in C# code you have to insert explicit casts.
I think it should be ok to disable the test for the target with a reference to the LLVM bug.

[AndyAyersMS]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

[Copilot]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

Updated in 7ec8799. The x64 Unix exclusion comment in Runtime_101046.ilproj now explicitly states this is due to LLVM’s non-standard ABI handling and links to llvm/llvm-project#43573.

[AndyAyersMS]

@jakobbotsch can you re-review

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046_1.cs:11

• The file header still says this is the reference source for the .il file, but after renaming the C# test to Runtime_101046_1 the corresponding IL variant is Runtime_101046.il (and its class/assembly name remains Runtime_101046). Please update the comment so it stays accurate and doesn’t imply the class names match.

[AndyAyersMS]

/ba-g unrelated failures

[Copilot]

• Diagnose: Runtime_101046.csproj and Runtime_101046.ilproj shared the same project name, so they shared OutputPath/IntermediateOutputPath and the generated .cmd/.sh wrapper and overwrote each other's outputs. After Enable out-of-process tests for CoreCLR browser WASM #131110 added a TestLibraryProjectReference + [ActiveIssue(typeof(PlatformDetection), ...)] to the C# variant only, NativeAOT builds could ILC-compile the C# assembly without TestLibrary in its reference set, so __GeneratedMainWrapper.Main() became a throwing body (FileNotFoundException: Could not find file 'TestLibrary').
• Rename the C# variant to Runtime_101046_1 (project, source file, test class) so the two tests no longer share output/intermediate directories
• Replace the TestLibrary-based ActiveIssue gate with the CLRTestTargetUnsupported project gate used by sibling native-asset tests
• Apply the same native-test-asset gate to the IL variant, which now actually runs
• Gate the IL variant off x64 Unix: once it really runs it fails there (JIT passes the un-normalized uint16, the clang-built callee assumes normalization) — needs a JIT-team decision, noted for follow-up
• Validate: built clr+libs and the test tree, ran both wrappers on linux-x64 (Runtime_101046_1 passes; IL variant excluded on x64 Unix)

• Fixes[ci-scan] Test failure: JIT/Regression/JitBlue/Runtime_101046 NativeAOT FileNotFoundException 'TestLibrary' #131997

[Copilot]

Copilot wasn't able to review any files in this pull request.

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046.ilproj:11

• The x64 Unix gating comment links to issue #131997, but that issue tracks a NativeAOT FileNotFoundException (TestLibrary) rather than the uint16 pinvoke normalization behavior described here. This makes the gate hard to audit later; please remove the incorrect link or replace it with the correct tracking issue for the normalization mismatch.

 <!-- The JIT only normalizes small primitive pinvoke arguments where the ABI requires it, but the
clang-compiled callee assumes normalization on x64 Unix: https://github.com/dotnet/runtime/issues/131997 -->
<CLRTestTargetUnsupported Condition="'$(TargetArchitecture)' == 'x64' and '$(TargetsUnix)' == 'true'">true</CLRTestTargetUnsupported>

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

[jakobbotsch]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?
Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

Yes, it is. See llvm/llvm-project#43573

[jakobbotsch]

I see -- well, that's unfortunate.

The original issue is #101046 and it was never based on a customer report, just from my reading of the ABIs. Normally you cannot hit that from C# code because in C# code you have to insert explicit casts.
I think it should be ok to disable the test for the target with a reference to the LLVM bug.

[AndyAyersMS]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

[Copilot]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

Updated in 7ec8799. The x64 Unix exclusion comment in Runtime_101046.ilproj now explicitly states this is due to LLVM’s non-standard ABI handling and links to llvm/llvm-project#43573.

[AndyAyersMS]

@jakobbotsch can you re-review

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046_1.cs:11

• The file header still says this is the reference source for the .il file, but after renaming the C# test to Runtime_101046_1 the corresponding IL variant is Runtime_101046.il (and its class/assembly name remains Runtime_101046). Please update the comment so it stays accurate and doesn’t imply the class names match.

[AndyAyersMS]

/ba-g unrelated failures

[Copilot]

• Diagnose: Runtime_101046.csproj and Runtime_101046.ilproj shared the same project name, so they shared OutputPath/IntermediateOutputPath and the generated .cmd/.sh wrapper and overwrote each other's outputs. After Enable out-of-process tests for CoreCLR browser WASM #131110 added a TestLibraryProjectReference + [ActiveIssue(typeof(PlatformDetection), ...)] to the C# variant only, NativeAOT builds could ILC-compile the C# assembly without TestLibrary in its reference set, so __GeneratedMainWrapper.Main() became a throwing body (FileNotFoundException: Could not find file 'TestLibrary').
• Rename the C# variant to Runtime_101046_1 (project, source file, test class) so the two tests no longer share output/intermediate directories
• Replace the TestLibrary-based ActiveIssue gate with the CLRTestTargetUnsupported project gate used by sibling native-asset tests
• Apply the same native-test-asset gate to the IL variant, which now actually runs
• Gate the IL variant off x64 Unix: once it really runs it fails there (JIT passes the un-normalized uint16, the clang-built callee assumes normalization) — needs a JIT-team decision, noted for follow-up
• Validate: built clr+libs and the test tree, ran both wrappers on linux-x64 (Runtime_101046_1 passes; IL variant excluded on x64 Unix)

• Fixes[ci-scan] Test failure: JIT/Regression/JitBlue/Runtime_101046 NativeAOT FileNotFoundException 'TestLibrary' #131997

[Copilot]

Copilot wasn't able to review any files in this pull request.

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046.ilproj:11

• The x64 Unix gating comment links to issue #131997, but that issue tracks a NativeAOT FileNotFoundException (TestLibrary) rather than the uint16 pinvoke normalization behavior described here. This makes the gate hard to audit later; please remove the incorrect link or replace it with the correct tracking issue for the normalization mismatch.

 <!-- The JIT only normalizes small primitive pinvoke arguments where the ABI requires it, but the
clang-compiled callee assumes normalization on x64 Unix: https://github.com/dotnet/runtime/issues/131997 -->
<CLRTestTargetUnsupported Condition="'$(TargetArchitecture)' == 'x64' and '$(TargetsUnix)' == 'true'">true</CLRTestTargetUnsupported>

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

[jakobbotsch]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?
Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

Yes, it is. See llvm/llvm-project#43573

[jakobbotsch]

I see -- well, that's unfortunate.

The original issue is #101046 and it was never based on a customer report, just from my reading of the ABIs. Normally you cannot hit that from C# code because in C# code you have to insert explicit casts.
I think it should be ok to disable the test for the target with a reference to the LLVM bug.

[AndyAyersMS]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

[Copilot]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

Updated in 7ec8799. The x64 Unix exclusion comment in Runtime_101046.ilproj now explicitly states this is due to LLVM’s non-standard ABI handling and links to llvm/llvm-project#43573.

[AndyAyersMS]

@jakobbotsch can you re-review

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046_1.cs:11

• The file header still says this is the reference source for the .il file, but after renaming the C# test to Runtime_101046_1 the corresponding IL variant is Runtime_101046.il (and its class/assembly name remains Runtime_101046). Please update the comment so it stays accurate and doesn’t imply the class names match.

[AndyAyersMS]

/ba-g unrelated failures

[Copilot]

• Diagnose: Runtime_101046.csproj and Runtime_101046.ilproj shared the same project name, so they shared OutputPath/IntermediateOutputPath and the generated .cmd/.sh wrapper and overwrote each other's outputs. After Enable out-of-process tests for CoreCLR browser WASM #131110 added a TestLibraryProjectReference + [ActiveIssue(typeof(PlatformDetection), ...)] to the C# variant only, NativeAOT builds could ILC-compile the C# assembly without TestLibrary in its reference set, so __GeneratedMainWrapper.Main() became a throwing body (FileNotFoundException: Could not find file 'TestLibrary').
• Rename the C# variant to Runtime_101046_1 (project, source file, test class) so the two tests no longer share output/intermediate directories
• Replace the TestLibrary-based ActiveIssue gate with the CLRTestTargetUnsupported project gate used by sibling native-asset tests
• Apply the same native-test-asset gate to the IL variant, which now actually runs
• Gate the IL variant off x64 Unix: once it really runs it fails there (JIT passes the un-normalized uint16, the clang-built callee assumes normalization) — needs a JIT-team decision, noted for follow-up
• Validate: built clr+libs and the test tree, ran both wrappers on linux-x64 (Runtime_101046_1 passes; IL variant excluded on x64 Unix)

• Fixes[ci-scan] Test failure: JIT/Regression/JitBlue/Runtime_101046 NativeAOT FileNotFoundException 'TestLibrary' #131997

[Copilot]

Copilot wasn't able to review any files in this pull request.

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046.ilproj:11

• The x64 Unix gating comment links to issue #131997, but that issue tracks a NativeAOT FileNotFoundException (TestLibrary) rather than the uint16 pinvoke normalization behavior described here. This makes the gate hard to audit later; please remove the incorrect link or replace it with the correct tracking issue for the normalization mismatch.

 <!-- The JIT only normalizes small primitive pinvoke arguments where the ABI requires it, but the
clang-compiled callee assumes normalization on x64 Unix: https://github.com/dotnet/runtime/issues/131997 -->
<CLRTestTargetUnsupported Condition="'$(TargetArchitecture)' == 'x64' and '$(TargetsUnix)' == 'true'">true</CLRTestTargetUnsupported>

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

[jakobbotsch]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?
Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

Yes, it is. See llvm/llvm-project#43573

[jakobbotsch]

I see -- well, that's unfortunate.

The original issue is #101046 and it was never based on a customer report, just from my reading of the ABIs. Normally you cannot hit that from C# code because in C# code you have to insert explicit casts.
I think it should be ok to disable the test for the target with a reference to the LLVM bug.

[AndyAyersMS]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

[Copilot]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

Updated in 7ec8799. The x64 Unix exclusion comment in Runtime_101046.ilproj now explicitly states this is due to LLVM’s non-standard ABI handling and links to llvm/llvm-project#43573.

[AndyAyersMS]

@jakobbotsch can you re-review

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046_1.cs:11

• The file header still says this is the reference source for the .il file, but after renaming the C# test to Runtime_101046_1 the corresponding IL variant is Runtime_101046.il (and its class/assembly name remains Runtime_101046). Please update the comment so it stays accurate and doesn’t imply the class names match.

[AndyAyersMS]

/ba-g unrelated failures

[Copilot]

• Diagnose: Runtime_101046.csproj and Runtime_101046.ilproj shared the same project name, so they shared OutputPath/IntermediateOutputPath and the generated .cmd/.sh wrapper and overwrote each other's outputs. After Enable out-of-process tests for CoreCLR browser WASM #131110 added a TestLibraryProjectReference + [ActiveIssue(typeof(PlatformDetection), ...)] to the C# variant only, NativeAOT builds could ILC-compile the C# assembly without TestLibrary in its reference set, so __GeneratedMainWrapper.Main() became a throwing body (FileNotFoundException: Could not find file 'TestLibrary').
• Rename the C# variant to Runtime_101046_1 (project, source file, test class) so the two tests no longer share output/intermediate directories
• Replace the TestLibrary-based ActiveIssue gate with the CLRTestTargetUnsupported project gate used by sibling native-asset tests
• Apply the same native-test-asset gate to the IL variant, which now actually runs
• Gate the IL variant off x64 Unix: once it really runs it fails there (JIT passes the un-normalized uint16, the clang-built callee assumes normalization) — needs a JIT-team decision, noted for follow-up
• Validate: built clr+libs and the test tree, ran both wrappers on linux-x64 (Runtime_101046_1 passes; IL variant excluded on x64 Unix)

• Fixes[ci-scan] Test failure: JIT/Regression/JitBlue/Runtime_101046 NativeAOT FileNotFoundException 'TestLibrary' #131997

[Copilot]

Copilot wasn't able to review any files in this pull request.

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046.ilproj:11

• The x64 Unix gating comment links to issue #131997, but that issue tracks a NativeAOT FileNotFoundException (TestLibrary) rather than the uint16 pinvoke normalization behavior described here. This makes the gate hard to audit later; please remove the incorrect link or replace it with the correct tracking issue for the normalization mismatch.

 <!-- The JIT only normalizes small primitive pinvoke arguments where the ABI requires it, but the
clang-compiled callee assumes normalization on x64 Unix: https://github.com/dotnet/runtime/issues/131997 -->
<CLRTestTargetUnsupported Condition="'$(TargetArchitecture)' == 'x64' and '$(TargetsUnix)' == 'true'">true</CLRTestTargetUnsupported>

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

[jakobbotsch]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?
Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

Yes, it is. See llvm/llvm-project#43573

[jakobbotsch]

I see -- well, that's unfortunate.

The original issue is #101046 and it was never based on a customer report, just from my reading of the ABIs. Normally you cannot hit that from C# code because in C# code you have to insert explicit casts.
I think it should be ok to disable the test for the target with a reference to the LLVM bug.

[AndyAyersMS]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

[Copilot]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

Updated in 7ec8799. The x64 Unix exclusion comment in Runtime_101046.ilproj now explicitly states this is due to LLVM’s non-standard ABI handling and links to llvm/llvm-project#43573.

[AndyAyersMS]

@jakobbotsch can you re-review

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046_1.cs:11

• The file header still says this is the reference source for the .il file, but after renaming the C# test to Runtime_101046_1 the corresponding IL variant is Runtime_101046.il (and its class/assembly name remains Runtime_101046). Please update the comment so it stays accurate and doesn’t imply the class names match.

[AndyAyersMS]

/ba-g unrelated failures

[Copilot]

• Diagnose: Runtime_101046.csproj and Runtime_101046.ilproj shared the same project name, so they shared OutputPath/IntermediateOutputPath and the generated .cmd/.sh wrapper and overwrote each other's outputs. After Enable out-of-process tests for CoreCLR browser WASM #131110 added a TestLibraryProjectReference + [ActiveIssue(typeof(PlatformDetection), ...)] to the C# variant only, NativeAOT builds could ILC-compile the C# assembly without TestLibrary in its reference set, so __GeneratedMainWrapper.Main() became a throwing body (FileNotFoundException: Could not find file 'TestLibrary').
• Rename the C# variant to Runtime_101046_1 (project, source file, test class) so the two tests no longer share output/intermediate directories
• Replace the TestLibrary-based ActiveIssue gate with the CLRTestTargetUnsupported project gate used by sibling native-asset tests
• Apply the same native-test-asset gate to the IL variant, which now actually runs
• Gate the IL variant off x64 Unix: once it really runs it fails there (JIT passes the un-normalized uint16, the clang-built callee assumes normalization) — needs a JIT-team decision, noted for follow-up
• Validate: built clr+libs and the test tree, ran both wrappers on linux-x64 (Runtime_101046_1 passes; IL variant excluded on x64 Unix)

• Fixes[ci-scan] Test failure: JIT/Regression/JitBlue/Runtime_101046 NativeAOT FileNotFoundException 'TestLibrary' #131997

[Copilot]

Copilot wasn't able to review any files in this pull request.

[azure-pipelines]

Azure Pipelines:
16 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046.ilproj:11

• The x64 Unix gating comment links to issue #131997, but that issue tracks a NativeAOT FileNotFoundException (TestLibrary) rather than the uint16 pinvoke normalization behavior described here. This makes the gate hard to audit later; please remove the incorrect link or replace it with the correct tracking issue for the normalization mismatch.

 <!-- The JIT only normalizes small primitive pinvoke arguments where the ABI requires it, but the
clang-compiled callee assumes normalization on x64 Unix: https://github.com/dotnet/runtime/issues/131997 -->
<CLRTestTargetUnsupported Condition="'$(TargetArchitecture)' == 'x64' and '$(TargetsUnix)' == 'true'">true</CLRTestTargetUnsupported>

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

[jakobbotsch]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?

Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

[AndyAyersMS]

@jakobbotsch do you think we need to extend the small type normalization in #106314 to linux x64 too?
Apparently clang depends on this and GCC does not.

What is the example where clang depends on that? I believe the upper bits are undefined in SysV so that sounds like a clang bug.

Yes, it is. See llvm/llvm-project#43573

[jakobbotsch]

I see -- well, that's unfortunate.

The original issue is #101046 and it was never based on a customer report, just from my reading of the ABIs. Normally you cannot hit that from C# code because in C# code you have to insert explicit casts.
I think it should be ok to disable the test for the target with a reference to the LLVM bug.

[AndyAyersMS]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

[Copilot]

@copilot can you update the test exclusion to mention the exclusion is for LLVM's non-standard ABI handling: llvm/llvm-project#43573

Updated in 7ec8799. The x64 Unix exclusion comment in Runtime_101046.ilproj now explicitly states this is due to LLVM’s non-standard ABI handling and links to llvm/llvm-project#43573.

[AndyAyersMS]

@jakobbotsch can you re-review

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

src/tests/JIT/Regression/JitBlue/Runtime_101046/Runtime_101046_1.cs:11

• The file header still says this is the reference source for the .il file, but after renaming the C# test to Runtime_101046_1 the corresponding IL variant is Runtime_101046.il (and its class/assembly name remains Runtime_101046). Please update the comment so it stays accurate and doesn’t imply the class names match.

[AndyAyersMS]

/ba-g unrelated failures