[generator] Investigate Throwable constructor-chain and partial-hook lifecycle coverage
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 48/100
- Issue 类型
- 功能
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 领域
- devtools, testing-qa
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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
Noneforwarding 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
- Inspect the existing hook test and Streams
IOExceptionfixture to confirm the missing combined inheritance/constructor/hook case. - Generate a two-level Throwable subclass chain containing bound Java constructors and distinct partial construction hooks.
- Check initializer selection and hook emission in actual generated output.
- Run the generated hierarchy against a real Android/JNI runtime, recording hook count/order and peer state before and after construction.
- 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.
- 主要语言
- C#
- 星标
- 2.1k
- 派生
- 579
- 平均合并
- 1 天 16 小时
- 30 天内合并 PR
- 258
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
dotnet/android 的其他 Issue
-
Area: App+Library Build
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
Area: Mono.Android
难度 2/5 1-3 小时 新手友好度 65/100
dotnet/android#9192 · 4 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
needs-triage
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 1 天内回复
-
agentic-workflows needs-triage
难度 3/5 1-2 天 新手友好度 45/100
dotnet/android#13325 · 1 条评论 ·
维护者通常 1 天内回复
-
Area: CoreCLR Area: Debugger bug needs-triage
难度 5/5 一周以上 新手友好度 24/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
possible bug
难度 2/5 1-3 小时 新手友好度 74/100
-
Include host.wslc.internal in the HTTPS development certificate可能已有人在做 @afscrome 今天认领。 未关闭area-commandlinetools
难度 2/5 1-3 小时 新手友好度 70/100
dotnet/aspnetcore#70122 · 1 条评论 ·
维护者通常 1 天内回复
-
:1st_place_medal: good first issue :cowboy_hat_face: refactor :roller_coaster: enhancement
难度 2/5 1-3 小时 新手友好度 68/100
ApplETS/Backend-Hello#78 ·
-
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 2 天内回复