[clr-ios] Disable R2R IL-body stripping for more library tests that need IL at run time by kotlarmilos · Pull Request #130468 · dotnet/runtime

kotlarmilos · 2026-07-10T10:04:01Z

Description

Follow-up to #130360. The SDK strips IL bodies from the Apple mobile CoreCLR composite ReadyToRun image by default, replacing each body with an invalid stub, so any test that needs the real IL at run time fails. Three more projects hit this: System.Runtime.Extensions.Tests (AppDomainTests.ExecuteAssembly invokes a stripped entry point, InvalidProgramException), System.IO.Hashing.Tests (Crc64ParameterSet.ForwardCrc64.InitializeVectorized, a Vector128 intrinsic fallback), and System.Diagnostics.StackTrace.Tests (the runtime-async V2Methods.Quuux in ToString_Async). This sets PublishReadyToRunStripILBodies to false on those three test projects, which #130360 already forwards through the _ApplePropertyNames allowlist, leaving stripping on for every other Apple mobile CoreCLR test app.

…eed IL at run time Follow-up to dotnet#130360. The SDK strips IL bodies from the Apple mobile CoreCLR composite ReadyToRun image by default, replacing each body with an invalid stub, so any test that needs the real IL at run time fails. Three more projects hit this: System.Runtime.Extensions.Tests (AppDomainTests.ExecuteAssembly invokes a stripped entry point, InvalidProgramException), System.IO.Hashing.Tests (Crc64ParameterSet.ForwardCrc64.InitializeVectorized, a Vector128 intrinsic fallback), and System.Diagnostics.StackTrace.Tests (the runtime-async V2Methods.Quuux in ToString_Async). This sets PublishReadyToRunStripILBodies to false on those three test projects, which dotnet#130360 already forwards through the _ApplePropertyNames allowlist, leaving stripping on for every other Apple mobile CoreCLR test app. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 432f1ad3-ea7c-4c6e-8f53-c6ecb80338b6

dotnet-policy-service · 2026-07-10T10:05:49Z

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

Copilot

Pull request overview

This PR updates a small set of library test projects to opt out of IL-body stripping during Apple mobile CoreCLR composite ReadyToRun publishing, ensuring tests that depend on runtime IL inspection/execution aren’t broken by stripped method bodies.

Changes:

Set PublishReadyToRunStripILBodies to false for System.Runtime.Extensions.Tests.
Set PublishReadyToRunStripILBodies to false for System.IO.Hashing.Tests.
Set PublishReadyToRunStripILBodies to false for System.Diagnostics.StackTrace.Tests.

Show a summary per file

File	Description
src/libraries/System.Runtime/tests/System.Runtime.Extensions.Tests/System.Runtime.Extensions.Tests.csproj	Disables IL-body stripping for this test app to keep runtime IL available where needed.
src/libraries/System.IO.Hashing/tests/System.IO.Hashing.Tests.csproj	Disables IL-body stripping for this test app to avoid failures when IL is required at runtime.
src/libraries/System.Diagnostics.StackTrace/tests/System.Diagnostics.StackTrace.Tests.csproj	Disables IL-body stripping for this test app to preserve IL-dependent runtime behavior for specific tests.

Copilot's findings

Files reviewed: 3/3 changed files
Comments generated: 0

kotlarmilos · 2026-07-10T10:11:15Z

/azp run runtime-extra-platforms

azure-pipelines · 2026-07-10T10:11:40Z

Azure Pipelines successfully started running 1 pipeline(s).

jakobbotsch · 2026-07-10T10:51:04Z

and System.Diagnostics.StackTrace.Tests (the runtime-async V2Methods.Quuux in ToString_Async)

Why is this manual workaround needed for this case?

…ple mobile The generated merged test runner entry point Program...RunTests(TestFilter) has its IL stripped by crossgen2 --strip-il-bodies, which the interpreter on Apple mobile CoreCLR needs at runtime, causing the iossimulator CoreCLR runtime test leg to fail. Set PublishReadyToRunStripILBodies=false so the property is forwarded through _ApplePropertyNames into the Helix Apple app build, matching the approach used for the library test projects in this PR. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 24b062cc-cf90-4c79-868e-4c6d1fcc7c36

Copilot

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 1

kotlarmilos · 2026-07-10T11:55:23Z

and System.Diagnostics.StackTrace.Tests (the runtime-async V2Methods.Quuux in ToString_Async)

Why is this manual workaround needed for this case?

The guard MayNeedILAtRuntime keeps IL only when ReturnsTaskOrValueTask() && !method.IsAsync. The guard is scoped to preserve IL of non-async Task returning methods. V2Methods.Quuux public static async Task Quuux() marked [RuntimeAsyncMethodGeneration(true)].

The alternative is to fix this by expanding the guard so IL is preserved for any Task or ValueTask returning method, that is dropping the, since both the non-async path and the async variant path read the same RVA IL.

kotlarmilos · 2026-07-10T11:56:36Z

/azp run runtime-extra-platforms

azure-pipelines · 2026-07-10T11:56:52Z

Azure Pipelines successfully started running 1 pipeline(s).

jakobbotsch · 2026-07-10T12:25:47Z

and System.Diagnostics.StackTrace.Tests (the runtime-async V2Methods.Quuux in ToString_Async)

Why is this manual workaround needed for this case?

The guard MayNeedILAtRuntime keeps IL only when ReturnsTaskOrValueTask() && !method.IsAsync. The guard is scoped to preserve IL of non-async Task returning methods. V2Methods.Quuux public static async Task Quuux() marked [RuntimeAsyncMethodGeneration(true)].

The alternative is to fix this by expanding the guard so IL is preserved for any Task or ValueTask returning method, that is dropping the, since both the non-async path and the async variant path read the same RVA IL.

The situation is:
For a method marked as async:

The IL is needed for the async variant
The IL is not needed for the Task-returning variant

For a method not marked as async:

The IL is needed for the async variant
The IL is needed for the Task-returning variant

The check checks for the second case and it expects the former case to be covered by the existing factory.OptimizationFlags.CompiledMethodDefs check. If that isn't the case, can we make it so it is?

CopiedMethodILNode stripped the RVA IL body of a runtime-async method whenever the method's Task-returning entrypoint was compiled, because the CompiledMethodDefs gate keys on the EcmaMethod while AsyncMethodVariant records itself under its own key. The RVA body is consumed at run time only by the async variant, so the body was stripped even when the variant was not compiled into the image and had to be materialized from IL, faulting on the invalid stub. Keep the IL for an already-async method unless its async variant is present in CompiledMethodDefs. This removes the need for the per-test PublishReadyToRunStripILBodies override on System.Diagnostics.StackTrace.Tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 24b062cc-cf90-4c79-868e-4c6d1fcc7c36

Copilot

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 3

kotlarmilos · 2026-07-10T13:06:18Z

/azp run runtime-extra-platforms

azure-pipelines · 2026-07-10T13:06:35Z

Azure Pipelines successfully started running 1 pipeline(s).

jakobbotsch · 2026-07-10T14:06:46Z

+                if (!method.IsAsync)
+                {
+                    // IL may be needed for async version of non-async Task-returning method
+                    return true;
+                }


If we are checking the async variant in some cases, should we just make this fully precise by checking it for this case too? If we've compiled both variants in this case then we won't need the IL at runtime.

Yes that makes sense

…g methods Check the async variant's compiled state uniformly for all Task/ValueTask-returning methods rather than keeping IL unconditionally for non-async ones. When both the Task-returning variant and its async variant are compiled the IL is fully consumed and can be stripped. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 24b062cc-cf90-4c79-868e-4c6d1fcc7c36

Copilot

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 2

… variant Covers the newly-precise guard: a non-async Task-returning method whose async variant is compiled (because a runtime-async method awaits it) now has its IL stripped. The case fails under the previous logic, which kept the IL of all non-async Task-returning methods unconditionally, and passes with the fix. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 24b062cc-cf90-4c79-868e-4c6d1fcc7c36

Copilot

Copilot's findings

Files reviewed: 6/6 changed files
Comments generated: 2

kotlarmilos · 2026-07-10T16:18:36Z

/azp run runtime-extra-platforms

azure-pipelines · 2026-07-10T16:18:50Z

Azure Pipelines successfully started running 1 pipeline(s).

Copilot AI review requested due to automatic review settings July 10, 2026 10:04

github-actions Bot added the area-System.Diagnostics label Jul 10, 2026

Copilot started reviewing on behalf of kotlarmilos July 10, 2026 10:04 View session

dotnet-policy-service Bot assigned kotlarmilos Jul 10, 2026

kotlarmilos requested review from jakobbotsch and vitek-karas July 10, 2026 10:04

kotlarmilos added area-Infrastructure and removed area-System.Diagnostics labels Jul 10, 2026

github-project-automation Bot added this to Runtime Infra Jul 10, 2026

kotlarmilos added this to the 11.0.0 milestone Jul 10, 2026