fix(language): Bind pl.create_tile to one function in both namespaces - #2266
fix(language): Bind pl.create_tile to one function in both namespaces#2266Hzfengsy wants to merge 1 commit into
Conversation
Fixes hw-native-sys#2265 `create_tile` resolved to two different functions. `pypto.language` imported it from `.op.tile_ops` (the `create_tile = create` alias, which accepts `transpose` and the keyword-only `flat_layout`), while `pypto.language.op` imported it from `.unified_ops`, whose forwarder declared only `(shape, dtype, target_memory)`. The DSL parser resolves unified `pl.<op>` calls against `pypto.language.op`, so inside a `@pl.function` body it got the narrow forwarder and rejected `transpose=` / `flat_layout=` — parameters that `inspect.signature`, IDE autocomplete and the docstring all advertise on the `pl.create_tile` a user can reach outside the parser. The unified block is imported after `tile_ops` so genuine Tensor/Tile dispatchers (`abs`, the bitwise family) win. That rationale never applied here: `create_tile` is Tile-only — the Tensor counterpart is a separately named `create_tensor` — and `unified_ops.create_tile` did no dispatch at all. It was a pure forwarder whose only effect was to narrow the signature. Delete the forwarder rather than widening it. Widening fixes today's symptom but leaves the duplicate definition, so the next parameter added to `tile_ops.create` reintroduces the identical bug. `tile_ops.create_tile` already aliases `create`, so the name stays exported from both namespaces. Add `test_namespaces_agree_on_shared_names`, which asserts every callable exported from both `pypto.language` and `pypto.language.op` resolves to the same object, so any future shadow of this class fails loudly.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe change removes the shadowing unified Changescreate_tile namespace alignment
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7c61a703f6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "shrs", | ||
| "set_validshape", | ||
| "create_tile", | ||
| "read", |
There was a problem hiding this comment.
Preserve the exported unified_ops.create_tile alias
Code importing create_tile directly from pypto.language.op.unified_ops now fails because this commit removes both the function and its __all__ entry, even though the module previously advertised it as exported. The duplicate wrapper can be eliminated without breaking that import path by retaining create_tile = _tile.create; this also provides the desired object identity and complete signature.
Useful? React with 👍 / 👎.
Summary
create_tileresolved to two different functions:pypto.language.create_tileop/tile_ops.py(create_tile = create)(shape, dtype, target_memory=Vec, transpose=None, *, flat_layout=None)pypto.language.op.create_tileop/unified_ops.py(shape, dtype, target_memory=Vec)The DSL parser resolves unified
pl.<op>calls againstpypto.language.op, so inside a@pl.functionbody it got the 3-parameter forwarder and rejectedtranspose=/flat_layout=— parameters thatinspect.signature, IDE autocomplete and the docstring all advertise on thepl.create_tilea user can reach everywhere else.The unified block is imported after
tile_opsso genuine Tensor/Tile dispatchers (abs, the bitwise family) win. That rationale never applied here:create_tileis Tile-only — the Tensor counterpart is a separately namedcreate_tensor— andunified_ops.create_tileperformed no dispatch at all. It was a pure forwarder whose only effect was to narrow the signature.Fix: delete the forwarder rather than widen it. Widening fixes today's symptom but leaves the duplicate definition in place, so the next parameter added to
tile_ops.createreintroduces the identical bug.tile_ops.create_tilealready aliasescreate, so the name stays exported from both namespaces.Changes
python/pypto/language/op/unified_ops.py__all__entry, and the now-unusedMemorySpaceimportpython/pypto/language/op/__init__.pycreate_tilefromtile_ops; correct both rationale commentstests/ut/language/test_unified_ops.pytranspose/flat_layoutregressionsdocs/{en,zh}/user/02-operation_reference.mdtranspose/flat_layoutsemanticscreate_tilewas the only name exported under both namespaces that resolved to two different objects — this was isolated, not systemic. Thepld/pld.opnamespaces have no equivalent divergence.Testing
tests/ut: 8579 passed, 2 skipped. The one failure,test_ir_trace.py::test_installed_console_script_preserves_main_exit_codes, asserts apypto-ir-traceconsole script exists in the environment; it is byte-identical onmainand unaffected by this change.test_namespaces_agree_on_shared_namesasserts every callable exported from bothpypto.languageandpypto.language.opresolves to the same object, so any future shadow of this class fails loudly. It was verified to fail against the pre-fix state.The two op regressions assert on the emitted layout (
slayout=col_major/none_box) rather than only that the call parses, so they also catch the failure mode where a kwarg is accepted and then silently dropped.Related Issues
Fixes #2265