[release/11.0] Fix CoreLib trimming substitutions for interpreter-only CoreCLR - #133664
Open
github-actions[bot] wants to merge 1 commit into
Open
[release/11.0] Fix CoreLib trimming substitutions for interpreter-only CoreCLR#133664github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
) ## Summary Fixes #133615. Only include CoreCLR's JIT-specific `IsDynamicCodeCompiled` trimming substitution when `FeatureDynamicCodeCompiled` is enabled. This matches the condition used by the original getter: interpreter-only CoreCLR can support dynamic code without compiling it. Normal JIT-enabled substitution behavior is unchanged. Reenable `RuntimeFeatureTests.DynamicCode` and `DynamicCode_Jit` on Apple-mobile CoreCLR by removing their #124344 exclusions. Narrow the existing #123011 interpreter exclusion to non-Apple platforms so the corrected result does not simply cause `DynamicCode_Jit` to be skipped. Retain `SkipOnMono`, the non-Apple interpreter exclusion, and all existing assertions. This is a standalone trimming fix. It does not depend on #133378 or include WASM library-test, CI, or stack-walk workaround changes. ## Validation Built clean baselines and rebuilt the modified CoreLib for macOS arm64 and iOS simulator arm64 using **Checked CoreCLR / Release libraries**. All builds completed without warnings or errors. On an **iOS 26.5 simulator**, ran the same `RuntimeFeatureTests` class selection with `PublishReadyToRun=false`. Test-selection changes were applied before the pre-fix run and remained identical afterward. | Configuration | Executed | Passed | Failed | |---|---:|---:|---:| | Pre-fix, aggressively trimmed iOS | 11 | 9 | 2 | | Pre-fix, untrimmed iOS control | 11 | 11 | 0 | | Post-fix, aggressively trimmed iOS | 11 | 11 | 0 | | Post-fix, normal macOS JIT | 13 | 13 | 0 | The two pre-fix failures were exactly `DynamicCode_Jit` (`IsDynamicCodeCompiled` unexpectedly true) and `DynamicCode` (direct getter disagrees with `IsSupported`). Both explicitly pass after the fix. Each iOS run has one unavailable RemoteExecutor context-switch case skipped; filtered cases are not counted as executed. Results were read from application logs, rather than relying on the local `xharness apple run` exit status. Additional controls: - Two fully trimmed desktop CoreLib/probe executions pass: dynamic-code support enabled preserves compiled=true; disabled preserves compiled=false. - ILLink direct-caller inspection confirms iOS compiled=false for either feature-switch value after the fix, while desktop true/false folding remains unchanged. No device, tvOS, MacCatalyst, or release-branch execution is claimed. ## Compatibility and servicing This corrects a public return value for affected trimmed interpreter-only CoreCLR applications; compatibility documentation should follow once the PR is merged. `release/11.0` and `release/11.0-rc1` have the same getter/substitution mismatch and are candidates for a targeted .NET 11 backport after main lands. `release/10.0` lacks the same no-JIT getter implementation, so this should not be mechanically backported there. > [!NOTE] > This pull request description and code changes were generated with GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
dotnet-policy-service
Bot
added
the
linkable-framework
|
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. |
Contributor
|
Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger |
Contributor
|
Tagging subscribers to this area: @dotnet/area-system-runtime |
vitek-karas
approved these changes
Sep 11, 2026
vitek-karas
left a comment
vitek-karas
left a comment
Member
There was a problem hiding this comment.
Looks good - I think @rolfbjarne should also take a look, since there were issues around this in iOS and I don't know how this will interact.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #133639 to release/11.0
iOS iterpreter and r2r+interp are current getting the wrong value for IsDynamicCodeCompiled due to an overly broad linker substitution
/cc @lewing
Customer Impact
[Select one or both of the boxes. Describe how this issue impacts customers, citing the expected and actual behaviors and scope of the issue. If customer-reported, provide the issue number.]
Regression
[If yes, specify when the regression was introduced. Provide the PR or commit if known.]
Testing
[How was the fix verified? How was the issue missed previously? What tests were added?]
Risk
[High/Medium/Low. Justify the indication by mentioning how risks were measured and addressed.]
IMPORTANT: If this backport is for a servicing release, please verify that:
release/X.0-staging, notrelease/X.0.release/X.0(no-stagingsuffix).Package authoring no longer needed in .NET 9
IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.