[dotnet-linker] Gate the TypeMap proxy-attribute workaround to .NET 10 only. Fixes #25276#26018
Conversation
…0 only The workaround for dotnet/runtime#127004 (adding the proxy type's attribute to the source type so ILLink's TypeMapHandler keeps the TypeMapAssociation) is no longer needed once the ILLink fix is available. The fix is only present in .NET 11+, so keep the workaround for .NET 10 and only stop applying it for .NET 11+: * In TrimmableRegistrarStep, only add the proxy attribute to the source type when targeting .NET 10 or earlier. * In TypeMaps (runtime), only read the workaround attribute from the source type for .NET 10 or earlier (gated with !NET11_0_OR_GREATER). Fixes #25276. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…indClass
When looking up the Objective-C class for a managed type, the trimmable
static registrar's FindClass looked up the *closed* generic type (e.g.
UIGestureRecognizer.Callback<UITapGestureRecognizer>) in the type maps.
However, generic types are registered using their generic type definition
(the maps are keyed by the *open* generic type, e.g. Callback`1), so the
lookup failed and the runtime tried to fall back to the dynamic registrar
(which has been linked away), throwing MT8026:
Can't register the class UIKit.UIGestureRecognizer+Callback`1[[UIKit.UITapGestureRecognizer, ...]] when the dynamic registrar has been linked away.
This was previously masked by the workaround for
dotnet/runtime#127004: reading the proxy attribute
directly off the closed generic type (Type.GetCustomAttribute) returns the
attribute stamped on the open generic definition, so the lookup happened to
succeed. Once that workaround was gated off for .NET 11+ (commit
d255353), the missing generic-type-definition reduction was exposed,
causing MT8026 (and, depending on timing, a NullReferenceException in
UIGestureRecognizer.OnDispose during finalization of an uninitialized
UITapGestureRecognizer).
Mirror the reduction already done in the non-trimmable FindClass path
(which does `if (type.IsGenericType) type = type.GetGenericTypeDefinition ()`).
Verified with:
make build run-bare -C tests/monotouch-test/dotnet/MacCatalyst \
TEST_VARIATION='trimmable-static-registrar-all-optimizations-linkall|release' CONFIG=Release \
RUN_ARGUMENTS="--test=MonoTouchFixtures.UIKit.GestureRecognizerTest.GenericCallbackTest"
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 22caaaa0-7267-4c5e-8c22-58e5b04e9f42
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Pull request overview
This PR updates the trimmable static registrar TypeMap workaround for the ILLink TypeMapHandler bug (dotnet/runtime#127004) so that it’s only applied for .NET 10 (and earlier), and is disabled for .NET 11+ where the upstream fix exists.
Changes:
- Gate the linker step’s “copy proxy attribute onto source type” workaround to
TargetFramework.Version.Major <= 10. - Gate the runtime
TypeMapsfallback that reads proxy attributes from the source type to!NET11_0_OR_GREATER. - Improve trimmable static registrar class-handle lookup for generic types by resolving via the open generic type definition.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| tools/dotnet-linker/Steps/TrimmableRegistrarStep.cs | Only applies the proxy-attribute workaround when targeting .NET 10 or earlier. |
| src/ObjCRuntime/TypeMaps.cs | Stops reading the workaround attribute on .NET 11+ builds (keeps it for .NET 10 and earlier). |
| src/ObjCRuntime/Class.cs | Normalizes constructed generic types to their generic type definition for trimmable TypeMap lookups. |
Comments suppressed due to low confidence (1)
src/ObjCRuntime/TypeMaps.cs:362
NSObjectProxyTypeslookups don't normalize constructed generic types to their generic type definition. The rest of the registration/type-map lookup logic (for exampleClass.FindClassandClass.GetTokenReference) normalizes generics before consulting maps, and the new comment here indicates the type maps are keyed by the open generic type. Without this normalization, callers that pass a closed generic type (e.g.Foo<int>) won't find the proxy mapping even thoughFoo<>is present.
#endif // !NET11_0_OR_GREATER
// end workaround for https://github.com/dotnet/runtime/issues/127004
if (!NSObjectProxyTypes.TryGetValue (managedType, out var proxyType)) {
#if LOG_TRIMMABLE_TYPEMAP
This comment has been minimized.
This comment has been minimized.
✅ API diff for current PR / commitNET (empty diffs)✅ API diff vs stableNET (empty diffs)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
🚀 [CI Build #70fb83f] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 199 tests passed 🎉 Tests counts✅ assembly-processing: All 1 tests passed. Html Report (VSDrops) Download macOS tests✅ Tests on macOS Monterey (12): All 5 tests passed. Html Report (VSDrops) Download Linux Build VerificationPipeline on Agent |
The workaround for dotnet/runtime#127004 (adding the proxy type's attribute to the source type so ILLink's TypeMapHandler keeps the TypeMapAssociation) is no longer needed once the ILLink fix is available.
The fix is only present in .NET 11+, so keep the workaround for .NET 10 and only stop applying it for .NET 11+:
TrimmableRegistrarStep, only add the proxy attribute to the source type when targeting .NET 10 or earlier.TypeMaps(runtime), only read the workaround attribute from the source type for .NET 10 or earlier (gated with!NET11_0_OR_GREATER).A separate validation-only PR targeting
net11.0(#26019) confirms everything still pass on .NET 11 with the workaround disabled (except the AppSizeTest test failed because NativeAOT app sizes went down ("App size changed significantly (-16,413 bytes)") - which is both expected and desirable).Fixes #25276
🤖 Pull request created by Copilot