Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#13,333 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp
Área
performance, tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
2.1k
Forks
579
Merge medio
1 d 16 h
PR fusionados (30 d)
258

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/android

Todos los issues de dotnet/android

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.