镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Discover type maps from the group defining assembly - #136606

Draft
jkoritzinsky wants to merge 1 commit into
dotnet:mainfrom
jkoritzinsky:dev/jkoritzinsky/type-map-group-scanning
Draft

jkoritzinsky wants to merge 1 commit into
dotnet:mainfrom
jkoritzinsky:dev/jkoritzinsky/type-map-group-scanning

Conversation

@jkoritzinsky

@jkoritzinsky jkoritzinsky commented Oct 28, 2026 •

Copy link
Copy Markdown
Member

I wanted to see if we could enable discovering type maps from the assembly that defines the group type to enable more cohesive usage for scenarios without app-wide analysis (like npgsql). Seems relatively clean, so I'm putting it up for review.

Approach

  • Add the group's defining assembly as a second root alongside the existing entry root, following group-specific assembly targets with shared deduplication.
  • Discover NativeAOT maps lazily from reachable external/proxy requests and discover ILLink groups as they are used. Preserve conditional trimming and independent activation of the two map kinds.
  • Keep entry-assembly selection and existing error behavior. The ReadyToRun representation is unchanged; CoreCLR uses the existing per-assembly cached-data or metadata paths.

Regression coverage includes transitive targets, cycles and overlapping roots, entry overrides, generic and array groups, unused groups, empty maps, conditional retention, and genuine duplicate keys. Newly discovered entries can expose duplicate keys that were previously ignored; existing duplicate-key rejection remains intentional.

Validation

Windows x64 validation passed:

  • ./build.cmd clr+libs+host -rc checked -lc release - clean baseline passed.
  • ./build.cmd clr.runtime+clr.tools -rc checked -lc release - changed VM, NativeAOT compiler, and Crossgen2 build passed.
  • ./src/tests/build.cmd generatelayoutonly x64 checked - passed.
  • ./src/tests/build.cmd test Interop\TypeMap\TypeMapDefiningAssemblyApp.csproj test Interop\TypeMap\TypeMapEntryAssemblyApp.csproj test Interop\TypeMap\TypeMapApp.csproj x64 checked skipnative - passed; all three generated wrappers passed with DOTNET_ReadyToRun=0.
  • The same test build with crossgen2 - passed; all three wrappers passed with RunCrossGen2=1 and the repository SDK selected for R2RDump.
  • The same test build with nativeaot - passed; all three native executables exited 100. Four existing IL3000 warnings concern Assembly.Location in R2R-only checks.
  • ./dotnet.cmd test src\tools\illink\test\Mono.Linker.Tests\Mono.Linker.Tests.csproj -c Debug --filter FullyQualifiedName~Mono.Linker.Tests.TestCases.Reflection.ReflectionTests - 55 passed.
  • ./dotnet.cmd test src\coreclr\tools\aot\ILCompiler.Trimming.Tests\ILCompiler.Trimming.Tests.csproj -c Checked --filter DisplayName~TypeMap -p:RuntimeConfiguration=Checked -p:LibrariesConfiguration=Release - 4 passed.

The defining-assembly regression failed before the fix in CoreCLR, NativeAOT, and ILLink. Linux and other architectures were not run.

Discovery cost

Release BenchmarkDotNet measurements on a Windows x64 VM, using identical map contents in both hosts:

Map creation Baseline Changed Managed allocation
External, same assembly 3.525 us 3.536 us 424 B, unchanged
Proxy, same assembly 4.272 us 4.366 us 1216 B, unchanged
External, additional CoreLib root 3.533 us 7.923 us 424 B, unchanged
Proxy, additional CoreLib root 4.362 us 8.802 us 1216 B, unchanged

Same-assembly discovery is deduplicated. Scanning CoreLib as an additional root adds about 4.4 us per creation in this measurement; this measures map creation, not dictionary lookup. Results are from a single Windows x64 VM, not cross-platform performance evidence.

Resolves #136575

Note

This pull request description and implementation were generated with GitHub Copilot.

Lazily discover group-specific mappings and assembly targets from reachable requests in CoreCLR, NativeAOT, and ILLink. Preserve entry-root contributions, trimming conditions, and duplicate detection.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@dotnet-policy-service dotnet-policy-service Bot added the linkable-framework Issues associated with delivering a linker friendly framework label Oct 28, 2026
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

@dotnet-policy-service

Copy link
Copy Markdown
Contributor

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

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-NativeAOT-coreclr linkable-framework Issues associated with delivering a linker friendly framework

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

Extend TypeMapAssemblyTarget scanning to defining assembly of TTypeMapGroup

1 participant