illink: Fix TypeMap instantiation not propagating to TypeMapAssociation entries#127452
Draft
illink: Fix TypeMap instantiation not propagating to TypeMapAssociation entries#127452
Conversation
…uirementsForInstantiatedTypes + test Agent-Logs-Url: https://github.com/dotnet/runtime/sessions/b98f3157-9724-49b7-92fe-29cfad891f1e Co-authored-by: jtschuster <36744439+jtschuster@users.noreply.github.com>
Copilot
AI
changed the title
[WIP] Fix TypeMap instantiation access modifier and update usage
illink: Fix TypeMap instantiation not propagating to TypeMapAssociation entries
Apr 27, 2026
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
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.
TypeMapHandler.MarkTypeMapAttributecalledAnnotations.MarkInstantiated(targetTypeDef)directly, bypassingMarkRequirementsForInstantiatedTypes. This meantProcessInstantiatedwas never called for the target type from that path — so anyTypeMapAssociationentries keyed on that target as source type would remain permanently unprocessed if the type was never independently instantiated by user code.Description
MarkStep.csMarkRequirementsForInstantiatedTypesfromprotected virtualtoprotected internal virtualto allowTypeMapHandler(same assembly) to call it directly.TypeMapHandler.cs_context.Annotations.MarkInstantiated(targetTypeDef)with_markStep.MarkRequirementsForInstantiatedTypes(targetTypeDef)inMarkTypeMapAttribute. This routes through the full instantiation pipeline, includingProcessInstantiated, which correctly enqueues or directly marks associatedTypeMapAssociationentries.TypeMap.cs(test)TypeMap<UsedTypeMap>whose target differs from its trim target, paired with aTypeMapAssociation<UsedTypeMap>where the source is that target type. The trim target is newed inMain; the target is only instantiated via TypeMap processing. Without the fix, theTypeMapAssociationattribute is silently dropped.Note
This PR description was generated with AI assistance (GitHub Copilot).
Original prompt
Apply the TypeMap instantiation fix on top of
mainindotnet/runtime, using the cleaner approach discussed in PR #127005 and comment #127005 (comment).Required code changes
In
src/tools/illink/src/linker/Linker.Steps/MarkStep.cs, changeMarkRequirementsForInstantiatedTypes(TypeDefinition type)fromprotected virtualtoprotected internal virtualso it remains available to subclasses while also being callable fromTypeMapHandlerin the same assembly.In
src/tools/illink/src/linker/Linker/TypeMapHandler.cs, replace the direct_context.Annotations.MarkInstantiated(targetTypeDef);call inMarkTypeMapAttributewith_markStep.MarkRequirementsForInstantiatedTypes(targetTypeDef);.Current intended diff shape against
main:Required tests
Bring over the test coverage from PR #127005 into
main. In particular, updatesrc/tools/illink/test/Mono.Linker.Tests.Cases/Reflection/TypeMap.csto cover a type used by bothTypeMapAttributeandTypeMapAssociationAttribute, ensuring both attributes are kept when the external TypeMap entry preserves the same source type.The PR’s test additions were approximately:
and in
Main:and near the end of the test file:
Adjust the exact placement to match current
mainand add any additional tests that seem necessary.Validation
Run an appropriate build and test for the changed area, and validate expected linker test outputs. At minimum, run the relevant ILLink test(s) for
Mono.Linker.Tests.Cases.Reflection.TypeMapif available in this repo. If full build/test is impractical, run the narrowest reliable commands and document what was run and the result.Notes
Prefer the
protected internalmodifier forMarkRequirementsForInstantiatedTypes, as requested.The following is the prior conversation context from the user's chat exploration (may be truncated):
User: #127005 (comment) Does this comment make sense to you? What would the diff look like if you were to implement it?
Assistant: Yes — the comment makes sense. The PR’s current fix manually compensates for calling
_context.Annotations.MarkInstantiated(targetTypeDef)directly, butMarkStep.MarkRequirementsForInstantiatedTypes()is the central path that already does the “a type became instantiated” work, including_typeMapHandler.ProcessInstantiated(type). So exposing that method toTypeMapHandlerand calling it should make the extraMarkAssociatedProxyTypeMapAttributeslogic unnecessary.A likely implementation diff would be: