[ILLink/ILCompiler] Fix crash when array types are used as TypeMap trim targets

[Copilot]

PublishTrimmed crashes with NotSupportedException: TypeDefinition cannot be resolved from 'Mono.Cecil.ArrayType' when a TypeMap attribute specifies an array type as its trim target (e.g., typeof(Foo[])).

Root cause (ILLink): LinkContext.Resolve throws for any TypeSpecification that isn't a GenericInstanceType. Array types, pointer types, and byref types all fall into this category.

Root cause (ILCompiler): ExternalTypeMapNode.GetConditionalStaticDependencies used context.NecessaryTypeSymbol(trimmingTargetType) as the condition node. When the trim target is Foo[], the TypeMap entry should be present whenever Foo (the element type) is reachable — but NecessaryTypeSymbol(Foo[]) is a different node from NecessaryTypeSymbol(Foo) and is only transitively marked when Foo[] itself is used. If code only uses Foo (e.g., new Foo()), the condition never fires and the entry is silently dropped.

Description

ILLink (TypeMapHandler.cs):

• TypeMapHandler.AddExternalTypeMapEntry: Strip non-resolvable TypeSpecification wrappers (array, pointer, byref, etc.) from the trim target before passing to RecordTypeMapEntry, using the element type instead.
• TypeMapHandler.AddProxyTypeMapEntry: Same fix applied symmetrically to the source type parameter. Corrected the comment to accurately state that TypeMapAssociationAttribute has two constructor type arguments (source and proxy).
• TypeMapHandler.MarkTypeMapAttribute: Same TypeSpecification-stripping fix applied before calling _context.Resolve(targetType).
• TypeMapHandler.UnwrapToResolvableType: The three previously duplicate stripping loops have been extracted into a single private static TypeReference UnwrapToResolvableType(TypeReference) helper, so future fixes only need to be made in one place. All call sites use idiomatic C# property pattern matching (TypeSpecification { ElementType: var elementType }) to avoid explicit casts.

ILCompiler (ExternalTypeMapNode.cs):

• ExternalTypeMapNode.GetEffectiveTrimTargetType: New private static helper that strips ParameterizedType wrappers (arrays, pointers, byrefs) to reach the element type. InstantiatedType (generics like List<T>) does not extend ParameterizedType and is correctly left alone.
• ExternalTypeMapNode.GetConditionalStaticDependencies and GetMarkedEntries: Updated to strip the trim target type via GetEffectiveTrimTargetType and use NecessaryTypeSymbol on the resulting element type. This matches ILLink's stripping behavior: the TypeMap entry is included whenever the element type is reachable (via new Foo(), is Foo casts, array construction new Foo[n], etc.), regardless of whether Foo[] itself is explicitly used.

// Before fix: crashes (ILLink) or silently drops entry (ILCompiler)
[assembly: TypeMap<TestTypeMap>("Key", typeof(SomeTarget), typeof(Foo[]))]

// After fix (ILLink): strips Foo[] → Foo, uses Foo as the trim dependency
// After fix (ILCompiler): strips Foo[] → Foo, uses NecessaryTypeSymbol(Foo) as the condition
// The TypeMap entry is included iff Foo (the element type) is trimmer-reachable

Both fixes handle nested arrays (Foo[][] → Foo), pointer types (Foo*[] → Foo), multi-dimensional arrays (Foo[,] → Foo), and mixed cases like List<Foo>[] (strips to List<Foo>, which is not a ParameterizedType).

Customer Impact

PublishTrimmed builds fail with an unhandled NotSupportedException / fatal ILLink error when any assembly attribute uses an array type as a TypeMap trim target. In ILCompiler (PublishAot), the TypeMap entry for an array trim target whose element type is reachable is silently dropped. No workaround short of removing the array type.

Regression

No — this is a new feature (TypeMap) that never handled array trim targets correctly in either ILLink or ILCompiler.

Testing

Added test cases to TypeMap.cs (ILLink / ILCompiler trimming tests):

• TrimTargetIsUsedArrayType: array trim target whose element type is reachable (via new ArrayTypeTrimTargetClass()) — attribute must be preserved; verified with KeptAttributeAttribute.
• TrimTargetIsUnusedArrayType: array trim target whose element type is unreachable — attribute and target types are removed; verified with explicit RemovedTypeInAssembly("test", ...) assertions on both ArrayTypeTrimTargetUnusedClass and ArrayTypeTrimTargetUnusedTarget.

Added TestInteropMapArrayTrimming to src/tests/nativeaot/SmokeTests/TrimmingBehaviors/DeadCodeElimination.cs (NativeAOT smoke test):

• 7 TypeMap entries (A–G) with array trim targets covering T[], T[,], and T*[] variants.
• MakeGenerics<T>() is a generic method that constructs TrimTarget1 [1], TrimTarget2 [1,1], TrimTarget3 *[1], and TrimTarget6[1], invoked via typeof(TestInteropMapArrayTrimming).GetMethod(nameof(MakeGenerics)).MakeGenericMethod([GetAtom()]).Invoke(null, []). Entry G is rooted via an is TrimTarget7[] cast.
• Atom class and GetAtom() method are present to provide the generic type argument for the reflection-based call.
• Struct declarations TrimTarget1 through TrimTarget4 use trailing spaces before the semicolon (e.g., TrimTarget1 ;) to visually distinguish the array-targeted trim types from the non-array ones.
• Verifies entries A, B, C, F, G are present in the map using TryGetValue; verifies entries D, E are absent (element type unreachable) also using TryGetValue — ContainsKey is not used because TypeMapLazyDictionary throws NotSupportedException for that method.

Both existing Reflection.TypeMap and Reflection.TypeMapEntryAssembly tests pass.

Risk

Low. The ILLink change is localized to TypeMapHandler — three call sites and one new private static helper. The ILCompiler change is localized to ExternalTypeMapNode — two methods updated and one new private static helper. The NativeAOT smoke test addition is additive only. No behavior change for existing valid (non-array) trim targets.

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.

[Copilot]

Pull request overview

Fixes an ILLink crash in PublishTrimmed when TypeMap attributes specify non-resolvable TypeSpecification types (notably arrays) as trim targets by stripping wrappers down to a resolvable element type before calling LinkContext.Resolve.

Changes:

• Normalize TypeMap trim targets and association source types by unwrapping TypeSpecification (array/pointer/byref/…) to an element type until reaching a TypeDefinition or GenericInstanceType.
• Add new linker test coverage for an array-type trim target scenario (kept case), and introduce a second unused-case scenario that should assert removal.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/tools/illink/src/linker/Linker/TypeMapHandler.cs	Unwraps TypeSpecification wrappers before resolving trim targets / proxy source types to avoid NotSupportedException crashes.
src/tools/illink/test/Mono.Linker.Tests.Cases/Reflection/TypeMap.cs	Adds test inputs for array-type trim targets and ensures at least the reachable-element case is preserved.

[jkoritzinsky]

@copilot please address the feedback from @copilot and validate test changes

[Copilot]

@copilot please address the feedback from @copilot and validate test changes

Done in af0ac93:

1. Added explicit RemovedTypeInAssembly("test", typeof(ArrayTypeTrimTargetUnusedClass)) and RemovedTypeInAssembly("test", typeof(ArrayTypeTrimTargetUnusedTarget)) assertions on the TypeMap class so the expected removal is explicitly verified by the test runner.
2. Fixed the misleading comment in AddProxyTypeMapEntry — it now says "two constructor type arguments (source and proxy)" instead of "single type argument".

Both Reflection.TypeMap and Reflection.TypeMapEntryAssembly tests still pass.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[MichalStrehovsky]

This fixes the correctness issue, but doesn't address #126177 (comment) the optimization on native AOT we could do if the element is a valuetype. I've set up the testing to ensure we have coverage of the areas off the top of my head where there are dragons (I expect the tests to fail on the first try at optimizing this).

Do we need the optimization too? If so, we need to add more tests that target the optimization and implement it. Cc @Sergio0694

[Sergio0694]

I mean, if we have to root all this stuff for reference types and take the size regression, it would surely be very welcome to get that optimization to at least try to minimize this for all projected structs/enum types, if possible, yes 😅

[MichalStrehovsky]

Native AOT part LGTM. We should do the possible optimization separately.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[github-actions]

test

Generated by Code Review for issue #126380 · ◷