Skip to content

codegen: skip composable .ctor on instance interfaces#23

Open
yeelam-gordon wants to merge 1 commit intomainfrom
leilzh/composable-ctor-skip
Open

codegen: skip composable .ctor on instance interfaces#23
yeelam-gordon wants to merge 1 commit intomainfrom
leilzh/composable-ctor-skip

Conversation

@yeelam-gordon
Copy link
Copy Markdown

Summary

Unsealed WinRT runtime classes expose a derived-from constructor on the default/required instance interface whose CLR method name is literally .ctor. It follows the COM aggregation pattern and is only meant to be invoked by a host framework (in practice XAML). Codegen used to fall through to the generic instance-method path and emit invalid syntax: def .ctor(self) -> None: in Python and .ctor(): void { ... } in TypeScript. Full-WinAppSDK smoke previously reported 62 affected files, all in Microsoft.UI.Xaml.*.

What changed

Early-return at the entry of the three per-method emitters:

  • project_instance_method (TS) -- project.rs
  • generate_iface_instance_method (Python) -- py_method.rs
  • emit_method_stub (Python .pyi stub) -- python_stub.rs

The .add_method(.ctor, ...) entry is still recorded in interface registration so vtable indices and parameterized-IID computation remain correct. Factory .ctor(args) (legitimate class construction) still routes through project_factory_method / generate_factory_method_invoke unchanged, and delegate .ctor + Invoke is still short-circuited to project_delegate / generate_delegate.

Verification

  • New tests/composable_ctor_test.rs (3 tests) pins all three behaviors: no .ctor declaration in TS / Python / .pyi output, and the interface registration still reserves a vtable slot per method.
  • Existing snapshot/cleanliness/tsc tests still pass -- Uri output unchanged.
  • Full Microsoft.UI.Xaml.Controls.Button generation: 383 .js / 383 .d.ts / 383 .py / 383 .pyi files, all syntactically valid:
    • python -m py_compile on every .py: 0 errors / 383 files
    • ast.parse on every .pyi: 0 errors / 383 files
    • 36 .ctor registrations preserved across the namespace (vtable correctness)

Out of scope

Full fix for actually invoking the composable constructor still requires implementing COM aggregation subclassing and XAML hosting -- out of scope until we take that on. This PR only stops codegen from emitting syntactically invalid output.

Unsealed WinRT runtime classes expose a derived-from constructor on the
default/required instance interface whose CLR method name is literally
`.ctor`. It follows the COM aggregation pattern and is only meant to
be invoked by a host framework (in practice XAML). Codegen used to fall
through to the generic instance-method path and emit invalid syntax:
`def .ctor(self) -> None:` in Python and `.ctor(): void { ... }` in
TypeScript. Full-WinAppSDK smoke previously reported 62 affected files,
all in `Microsoft.UI.Xaml.*`.

Fix: early-return at the entry of the three per-method emitters:

  - `project_instance_method` (TS)
  - `generate_iface_instance_method` (Python)
  - `emit_method_stub` (Python `.pyi` stub)

The `.add_method(`.ctor`, ...)` entry is still recorded in interface
registration so vtable indices and parameterized-IID computation remain
correct. Factory `.ctor(args)` (legitimate class construction) still
routes through `project_factory_method` / `generate_factory_method_invoke`
unchanged, and delegate `.ctor + Invoke` is still short-circuited to
`project_delegate` / `generate_delegate`.

Verification:
  - New `tests/composable_ctor_test.rs` pins all three behaviors:
    no `.ctor` declaration in TS / Python / `.pyi` output, and the
    interface registration still reserves a vtable slot per method.
  - Existing snapshot/cleanliness/tsc tests still pass (Uri output
    unchanged).
  - Full Microsoft.UI.Xaml.Controls.Button generation: 383 `.js` /
    383 `.d.ts` / 383 `.py` / 383 `.pyi` files, all syntactically
    valid (`python -m py_compile` and AST-parse on every file, zero
    errors). 36 `.ctor` registrations preserved across the namespace.

Full fix for actually *invoking* the composable constructor still
requires implementing COM aggregation subclassing and XAML hosting --
out of scope until we take that on.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant