Delete vestiges of universal shared code support #113640
Conversation
ghost
added
the
There was a problem hiding this comment.
Pull Request Overview
This PR removes the remaining support for universal canonical templates and shared code for generics throughout the type loader and runtime environment. Key changes include the deletion of functions and branches dedicated to universal canonical processing, the removal of related assertions and debug comments, and updates to API calls that now default to using specific canonical forms.
Reviewed Changes
Copilot reviewed 41 out of 41 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/coreclr/nativeaot/System.Private.TypeLoader/src/Internal/TypeSystem/TypeDesc.Runtime.cs | Removed IsTemplateUniversal and simplified IsTemplateCanonical |
| src/coreclr/nativeaot/System.Private.TypeLoader/src/Internal/Runtime/TypeLoader/TypeBuilderState.cs | Removed universal-specific checks when computing native layout info |
| src/coreclr/nativeaot/System.Private.TypeLoader/src/Internal/TypeSystem/CanonTypes.Runtime.cs | Updated canon type initialization to use the overload without the canonical kind parameter |
| Various | Removed branches and parameters related to universal canonical support in type resolution, mapping tables, and invocation metadata |
Comments suppressed due to low confidence (2)
src/coreclr/nativeaot/System.Private.TypeLoader/src/Internal/TypeSystem/TypeSystemContext.Runtime.cs:190
- Confirm that removing the UniversalCanonType.RuntimeTypeHandle check does not impact type resolution in any edge cases.
else if (rtth.Equals(UniversalCanonType.RuntimeTypeHandle))
src/coreclr/nativeaot/System.Private.Reflection.Execution/src/Internal/Reflection/Execution/ExecutionEnvironmentImplementation.MappingTables.cs:290
- Verify that eliminating the explicit canonical form selection in the lookup does not lead to mismatches for methods that previously relied on universal canonical paths.
MethodInvokeInfo methodInvokeInfo = TryGetMethodInvokeInfo(declaringTypeHandle, methodHandle, genericMethodTypeArgumentHandles, methodInfo);
| private CanonicalFormKind _canonKind; | ||
|
|
||
| public CanonicallyEquivalentEntryLocator(RuntimeTypeHandle typeToFind, CanonicalFormKind kind) | ||
| public CanonicallyEquivalentEntryLocator(RuntimeTypeHandle typeToFind) |
There was a problem hiding this comment.
Ensure that defaulting to CanonicalFormKind.Specific for all canonical comparisons is intended and thoroughly tested after removing universal canonical support.
| } | ||
|
|
||
| return _lookupMethodInfo.CanInstantiationsShareCode(_methodInstantiation, _canonFormKind); | ||
| return _lookupMethodInfo.CanInstantiationsShareCode(_methodInstantiation, CanonicalFormKind.Specific); |
There was a problem hiding this comment.
Is deleting CanonicalFormKind left for a future PR? Or do you believe that it is worth it to preserve it?
There was a problem hiding this comment.
I'm not deleting it from the type system, just in case we want it for ReadyToRun at some point. It is in a leafy location there.
2 participants
No description provided.