Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#13,334 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, java
Lĩnh vực
devtools, testing-qa

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C#
Star
2.1k
Fork
579
Merge trung bình
1 ngày 16 giờ
Pull request đã merge (30 ngày)
258

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của dotnet/android

Tất cả issue của dotnet/android

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.