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

[generator] Investigate Throwable constructor-chain and partial-hook lifecycle coverage

Aperta
  • Qualcosa non va?
#13,334 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
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp, java
Ambito
devtools, testing-qa

Direzione di ricerca

Start with PeerConstructorPartialMethod_Class in CodeGeneratorTests.cs, then trace forwarding and initializer selection in BoundClass.cs and BoundConstructor.cs; compare the Streams IOException snapshot. Run the generator tests, then investigate a two-level Throwable hierarchy on a real Android/JNI runtime. Done means focused output and lifecycle coverage distinguishes hook count/order and peer validity without treating compile-only probes as native coverage.

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

Descrizione

Area: Mono.Bindings needs-triage
Android framework version

net11.0-android (Preview) — generator and runtime coverage follow-up; also distinguish legacy compilation from updated memory-safety-rules probes.

Affected platform version

Binding-constructor preparation reviewed in #13190 at commit e4473175aba5271fd839d0a1dd8b3777a8ca5f90. This is a coverage gap, not an observed runtime regression.

Description

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

Investigate and improve coverage of generated Throwable construction through the internal JniObjectReferenceOptions.None forwarding route, especially with inheritance and peerConstructorPartialMethod hooks.

The existing PeerConstructorPartialMethod_Class test checks emitted text for an ordinary Object-derived class. The Streams IOException snapshot has a forwarding declaration but no bound Java constructors or partial hooks. Earlier session-only generated-chain/compiler probes covered constructor selection and implementation/reference accessibility, not actual hook execution order or real Java-peer creation. Passing compiler probes must not be presented as native lifecycle coverage.

A focused follow-up should investigate a two-level generated Throwable inheritance chain with bound Java constructors and hooks, then add appropriately scoped coverage for:

  • Ordinary managed constructors selecting the None forwarding route.
  • Hooks running exactly once, in base-to-derived order, before a Java peer is installed.
  • Normal construction subsequently yielding a valid Java peer.
  • Existing initialization, dispatch and cleanup behavior remaining intact.

Separate generator-output assertions from actual Android/JNI lifecycle tests; a synthetic handle or compile-only peer model does not prove a valid native peer.

The originating PR is an unsafe audit, not a general refactoring or test-coverage expansion. No behavioral bug has been demonstrated here, and the user explicitly requested tracking this improvement separately. This issue is also distinct from the known cross-assembly updated-rules constructor-initializer limitation: internal forwarding does not provide external assemblies with an accessible safe base constructor, and the corresponding CS9362 probe remains an unresolved design boundary, not a runtime failure reproduced by this issue.

Relevant source:

  • external/Java.Interop/tools/generator/SourceWriters/BoundClass.cs: forwarding constructor and partial hook emission.
  • external/Java.Interop/tools/generator/SourceWriters/BoundConstructor.cs: initializer selection and JNI peer construction.
  • external/Java.Interop/tests/generator-Tests/Unit-Tests/CodeGeneratorTests.cs: PeerConstructorPartialMethod_Class.
  • external/Java.Interop/tests/generator-Tests/expected.xaji/Streams/Java.IO.IOException.cs.
  • external/Java.Interop/Documentation/Architecture.md: generated managed binding safety and cross-assembly limitation.
Steps to Reproduce
  1. Inspect the existing hook test and Streams IOException fixture to confirm the missing combined inheritance/constructor/hook case.
  2. Generate a two-level Throwable subclass chain containing bound Java constructors and distinct partial construction hooks.
  3. Check initializer selection and hook emission in actual generated output.
  4. Run the generated hierarchy against a real Android/JNI runtime, recording hook count/order and peer state before and after construction.
  5. Document findings and add focused regression/coverage tests appropriate to any behavior demonstrated. Do not silently change constructor accessibility, public API, caller contracts or language settings to make the tests pass.
Did you find any workaround?

N/A. No runtime failure or workaround has been established; the current gap is missing focused behavioral coverage.

Relevant log output

N/A. No failing lifecycle trace is available. Existing compile/accessibility evidence does not establish hook execution or native peer validity.

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.