Fix LoadExactInterfaceMap for sub-interfaces with complex type arguments under special marker parents#124684
Open
davidwrighton wants to merge 4 commits intodotnet:mainfrom
Open
Fix LoadExactInterfaceMap for sub-interfaces with complex type arguments under special marker parents#124684davidwrighton wants to merge 4 commits intodotnet:mainfrom
davidwrighton wants to merge 4 commits intodotnet:mainfrom
Conversation
…nts under special marker parents When pNewIntfMT is a special marker type and its sub-interface has an exact instantiation containing complex type arguments (e.g. IList(Of T) rather than bare T), the previous code would fall through to case 4 which checked EligibleForSpecialMarkerTypeUsage against pMT. This could incorrectly treat the sub-interface as an exact match when it still contains unresolved generic variables. Split old case 4 into three new cases: - Case 4: pNewIntfMT is a special marker type and the sub-interface's instantiation is eligible for special marker usage relative to pNewIntfMT (e.g. ILayer1(Of T) where T matches). Insert the marker. - Case 5: pNewIntfMT is a special marker type but the sub-interface has generic variables that don't match (e.g. ILayer1(Of IList(Of T))). Trigger retry with exact interfaces since full substitution is needed. - Case 6: The sub-interface is fully concrete or pNewIntfMT is not a special marker. Fall through to the existing pMT-based eligibility check. Add regression tests covering all 8 combinations of pre-loading the 3 interface layers. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes CoreCLR interface-map exact-loading for the case where a special marker parent interface contains a sub-interface entry that is an exact instantiation with more complex type arguments (e.g., IList<T>), preventing incorrect eligibility checks and ensuring the algorithm falls back to the exact-interface retry path when deep substitution would be required.
Changes:
- Split the prior “exact instantiation” handling in
LoadExactInterfaceMapinto additional sub-cases to correctly handle special-marker parents and open generic variables. - Add a VB regression test suite (with 8 preload-order combinations) to exercise the special marker interface map logic and validate the fix.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| src/coreclr/vm/methodtablebuilder.cpp | Refines LoadExactInterfaceMap handling for exact sub-interfaces under special marker parents, including a controlled fallback path. |
| src/tests/Loader/classloader/regressions/GitHub_124369/GitHub_124369.vb | Adds VB regression coverage for the reported failure mode across multiple preload orderings and interface layering shapes. |
| src/tests/Loader/classloader/regressions/GitHub_124369/GitHub_124369.vbproj | Adds the test project definition for the new VB regression test. |
This was referenced Feb 21, 2026
Open
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
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
1 participant
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.
Summary
When
pNewIntfMTis a special marker type and its sub-interface in the interface map has an exact instantiation containing complex type arguments (e.g.IList<T>rather than bareT), the previous code inLoadExactInterfaceMapwould incorrectly fall through to the old case 4 logic. This checkedEligibleForSpecialMarkerTypeUsageagainstpMTrather thanpNewIntfMT, which could treat a sub-interface still containing unresolved generic variables as either eligible for special marker substitution or as an exact match — both incorrect.Fix
The old case 4 (exact instantiation) is split into three cases to correctly handle the situation where
pNewIntfMTis itself a special marker type:pNewIntfMT(e.g.ILayer1<T>whereTmatchespNewIntfMT's type parameter). Insert the special marker type.pNewIntfMT's type parameter (e.g.ILayer1<IList<T>>). Since resolving this requires a full deep substitution, and this is a rare scenario, we fall back to the retry-with-exact-interfaces pathway which setsMayHaveOpenInterfacesInInterfaceMapand disables the special marker optimization for this type.pNewIntfMTis not a special marker type. Falls through to the existingpMT-based eligibility check, which is correct in these situations.A regression test is added covering all 8 combinations of pre-loading the 3 interface layers' generic type definitions before constructing the concrete class, to exercise the various orderings that lead to different code paths through the special marker type logic.
Fixes #124369