Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[generator] Investigate deferred-constructor capability scanning with shallow reference imports

Aperta
  • Qualcosa non va?
#13,333 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
performance, tooling

Direzione di ricerca

Read CecilApiImporter.cs around CreateClass() and its populate action, then trace Lookup() and EnsurePopulated() in SymbolTable.cs to understand when shallow imports are populated. Compare the existing eager scan with the same predicate during population, measuring equivalent inputs in shallow and eager modes. Done means the cost is assessed and generated source and accessible-constructor detection remain unchanged; do not claim a speedup without measurements.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

needs-triage
Android framework version

Other — generator/tooling investigation; not specific to an Android application target framework.

Affected platform version

Binding generator as reviewed in #13190 at commit e4473175aba5271fd839d0a1dd8b3777a8ca5f90. No measured performance regression or SDK-version threshold has been established.

Description

Follow-up to https://github.com/dotnet/android/pull/13190#discussion_r4421307003.

CecilApiImporter.CreateClass() computes HasDeferredThrowableConstructor in the class initializer by scanning TypeDefinition.Methods and constructor parameter/attribute metadata. UseShallowReferencedTypes defaults to true, but CodeGenerator.ProcessReferencedType() constructs class models for imported reference classes before knowing whether consumers will look them up. The new capability check therefore adds eager metadata work even for otherwise unused shallow imports.

Investigate the practical cost and whether the capability check should run inside the existing populate action instead. Symbol-table lookup already populates imported bases before the generator consumes this capability. Preserve the existing constructor-accessibility/type/RequiresUnsafe predicate and keep detection outside the registered-member filter: a qualifying forwarding constructor is deliberately unregistered, while an inaccessible internal constructor must not qualify for an external consumer.

This is deferred investigation and performance work, not a claim of a measured slowdown or a constructor correctness bug. The originating PR is an unsafe audit, not a general refactoring or performance-optimization effort. The user explicitly requested tracking this suggestion separately rather than broadening that PR.

Relevant source:

  • external/Java.Interop/tools/generator/Java.Interop.Tools.Generator.Importers/CecilApiImporter.cs: CreateClass() and its populate action.
  • external/Java.Interop/tools/generator/CodeGenerationOptions.cs: UseShallowReferencedTypes.
  • external/Java.Interop/tools/generator/Java.Interop.Tools.Generator.ObjectModel/Symbols/SymbolTable.cs: Lookup() / EnsurePopulated().
  • external/Java.Interop/tools/generator/SourceWriters/Extensions/SourceWriterExtensions.cs: UsesDeferredThrowableConstructor().
Steps to Reproduce
  1. Import reference assemblies with shallow reference types enabled, including many types that are never looked up from the symbol table.
  2. Compare the current eager capability scan with the same predicate evaluated when a referenced class is populated.
  3. Measure metadata/import work and representative end-to-end generator time under equivalent inputs; do not infer a quantified speedup from static inspection alone.
  4. Check shallow and eager import modes and confirm generated source and accessible-constructor detection remain unchanged.
Did you find any workaround?

N/A. No user-visible workaround is proposed. Moving the scan into populate is a candidate to evaluate in the follow-up, not a change already applied by this issue.

Relevant log output

N/A. This records a source-review observation; no timing benchmark or performance failure was collected.

Lingua principale
C#
Stelle
2.1k
Fork
579
Merge medio
1g 16h
PR unite (30g)
258

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/android

Tutte le issue di dotnet/android

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.