Implement trimming support for the Interop Type Map #116555

jkoritzinsky · 2025-06-11T19:33:26Z

Depends on #116355

Completes #110691

dotnet-policy-service · 2025-06-11T19:34:14Z

Tagging subscribers to this area: @dotnet/illink
See info in area-owners.md if you want to be subscribed.

src/tools/illink/src/linker/Linker/TypeMapHandler.cs

…pe is marked

…ttributes. We now trim the type map attributes centrally.

…immer. Only emit it from the analyzer

sbomer · 2025-06-20T20:29:13Z

src/tools/illink/src/linker/Linker.Steps/MarkStep.cs

@@ -90,6 +92,8 @@ internal DynamicallyAccessedMembersTypeHierarchy DynamicallyAccessedMembersTypeH
 			}
 		}

+		internal TypeMapHandler TypeMapHandler => _typeMapHandler;


I think this is unused

src/tools/illink/src/ILLink.Shared/TrimAnalysis/Intrinsics.cs

sbomer · 2025-06-20T20:54:26Z

src/tools/illink/src/linker/Linker/LinkContext.cs

@@ -742,6 +742,11 @@ public bool IsWarningSuppressed (int warningCode, string subcategory, MessageOri
 			if (Suppressions == null)
 				return false;

+			// Don't warn for RUC on assembly attributes.
+			// There's no way to suppress it.
+			if (warningCode == 2026 && origin.Provider is AssemblyDefinition)


Suggested change

if (warningCode == 2026 && origin.Provider is AssemblyDefinition)

if (warningCode == DiagnosticId.RequiresUnreferencedCode && origin.Provider is AssemblyDefinition)

sbomer · 2025-06-20T20:56:21Z

src/tools/illink/src/linker/Linker/Annotations.cs

+
+		public void SetEntryPointAssembly(AssemblyDefinition asmDef)
+		{
+			Debug.Assert (entry_assembly is null);


There might be multiple root assemblies. Could we just give all root assemblies this treatment?

We specifically want to have the "assembly with the entrypoint main method" be the one that roots type map discovery. We don't want to scan type maps for assemblies that are separately fully rooted.

src/tools/illink/src/linker/Linker.Steps/MarkStep.cs

sbomer · 2025-06-20T21:09:23Z

src/tools/illink/src/linker/Linker/TypeMapHandler.cs

+			RecordTargetTypeSeen (definition, _unmarkedExternalTypeMapEntries, _referencedExternalTypeMaps, _pendingExternalTypeMapEntries);
+		}
+
+		void RecordTargetTypeSeen (TypeDefinition targetType, Dictionary<TypeDefinition, Dictionary<TypeReference, List<CustomAttributeWithOrigin>>> unmarkedTypeMapAttributes, HashSet<TypeReference> referenceTypeMapGroups, Dictionary<TypeReference, List<CustomAttributeWithOrigin>> typeMapAttributesPendingUniverseMarking)


nit: format these with one argument per line

sbomer · 2025-06-20T21:40:20Z

src/tools/illink/src/linker/Linker/TypeMapHandler.cs

+				return;
+			}
+			if (attr.Attribute.ConstructorArguments is [_, { Value: TypeReference target }]) {
+				// This is a TypeMapAssemblyTargetAttribute, which has a single type argument.


This comment doesn't seem to match the check

Currently it looks like the two forms of the external type map attribute both use the same logic for trimTarget and target - is that intentional? My understanding was that the trimTarget variant was supposed to be the only one that participates in the conditional logic, and the (string, Type target) variant was supposed to be kept whether or not the target type is otherwise marked.

I implemented it in this way with the NativeAOT implementation and updated the design doc (commited in that PR) with the adjusted rule.

I believe that with the expanded rules for including trimTarget entries, it's impossible to tell the difference in a correctly-written app if the (string, Type) overload always preserves or only does when the Type is marked.

If there's an instance of the (string, Type) attribute with an otherwise unused type, I am expecting the external type mapping to contain this entry. Whereas for an instance of the (string, Type target, Type trimTarget) overload with an otherwise unused trimTarget, I expect it not to contain this entry. Is that right? @AaronRobinsonMSFT

sbomer · 2025-06-20T21:43:19Z

src/tools/illink/src/linker/Linker/TypeMapHandler.cs

+		void AddProxyTypeMapEntry (TypeReference group, CustomAttributeWithOrigin attr)
+		{
+			if (attr.Attribute.ConstructorArguments is [{ Value: TypeReference sourceType }, _]) {
+				// This is a TypeMapAssociationAttribute, which has a single type argument.


nit: comment is slightly misleading since the attribute has two type arguments

sbomer · 2025-06-20T21:50:45Z

src/tools/illink/src/linker/ref/Linker.Steps/MarkContext.cs

@@ -13,5 +13,9 @@ public abstract class MarkContext
 		public abstract void RegisterMarkTypeAction (Action<TypeDefinition> action);

 		public abstract void RegisterMarkMethodAction (Action<MethodDefinition> action);
+
+		public virtual void RegisterMarkInstantiatedAction (Action<TypeDefinition> action)


unused I think

jkoritzinsky added blocked Issue/PR is blocked on something - see comments area-Tools-ILLink .NET linker development as well as trimming analyzers labels Jun 11, 2025

jkoritzinsky mentioned this pull request Jun 10, 2025

Interop Type Mapping #110691

Open

9 tasks

dotnet-policy-service bot added the linkable-framework Issues associated with delivering a linker friendly framework label Jun 11, 2025

dotnet-policy-service bot assigned jkoritzinsky Jun 11, 2025

jkoritzinsky added this to the 10.0.0 milestone Jun 11, 2025

jkoritzinsky linked an issue Jun 11, 2025 that may be closed by this pull request

Interop Type Mapping #110691

Open

9 tasks

jtschuster reviewed Jun 13, 2025

View reviewed changes

src/tools/illink/src/linker/Linker/TypeMapHandler.cs Outdated Show resolved Hide resolved

jkoritzinsky added 5 commits June 20, 2025 12:33

Add handler to mark type map custom attributes when the triggering ty…

0bb15a6

…pe is marked

Reimplement as part of MarkStep.

680a073

Don't special-case type map attributes in AddDependenciesDueToCustomA…

ed28bab

…ttributes. We now trim the type map attributes centrally.

Don't emit the warning for RUC on the assembly attributes from the tr…

55e9d2b

…immer. Only emit it from the analyzer

PR feedback

63c3153

jkoritzinsky force-pushed the typemap-illink branch from 74ad0a4 to 63c3153 Compare June 20, 2025 19:37

jkoritzinsky marked this pull request as ready for review June 20, 2025 19:37

jkoritzinsky requested review from marek-safar, sbomer and MichalStrehovsky as code owners June 20, 2025 19:37

jkoritzinsky added 2 commits June 20, 2025 13:04

Fix typo

7509663

Adjust test

8af7a56

This was referenced Jun 20, 2025

browser-wasm windows Debug AllSubsets_CoreCLR builds failing in emcc seemingly unrelated to any code issues #116647

Open

Occasional failure in "browser-wasm windows Release LibraryTests: Build Product" #116671

Open

browser-wasm Windows build error #116746

Open

sbomer reviewed Jun 20, 2025

View reviewed changes

build-analysis bot mentioned this pull request Jun 20, 2025

[iOS/tvOS] System.Runtime.Tests crash with signal 4 #116815

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Implement trimming support for the Interop Type Map #116555

Implement trimming support for the Interop Type Map #116555

jkoritzinsky commented Jun 11, 2025 •

edited

Loading

Uh oh!

dotnet-policy-service bot commented Jun 11, 2025

Uh oh!

Uh oh!

sbomer Jun 20, 2025

Uh oh!

Uh oh!

sbomer Jun 20, 2025

Uh oh!

sbomer Jun 20, 2025

Uh oh!

jkoritzinsky Jun 20, 2025

Uh oh!

Uh oh!

sbomer Jun 20, 2025

Uh oh!

sbomer Jun 20, 2025

Uh oh!

sbomer Jun 20, 2025

Uh oh!

jkoritzinsky Jun 20, 2025

Uh oh!

sbomer Jun 20, 2025

Uh oh!

sbomer Jun 20, 2025

Uh oh!

sbomer Jun 20, 2025

Uh oh!

Uh oh!

	if (warningCode == 2026 && origin.Provider is AssemblyDefinition)
	if (warningCode == DiagnosticId.RequiresUnreferencedCode && origin.Provider is AssemblyDefinition)

Implement trimming support for the Interop Type Map #116555

Are you sure you want to change the base?

Implement trimming support for the Interop Type Map #116555

Conversation

jkoritzinsky commented Jun 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-service bot commented Jun 11, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jkoritzinsky commented Jun 11, 2025 •

edited

Loading