-
Notifications
You must be signed in to change notification settings - Fork 1.4k
overridable validate_downcastable_from #6393
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WalkthroughUpdates PyPayload trait to introduce a validate_downcastable_from extension point for custom downcast validation. Modifies PyUtf8Str to use this hook for UTF-8 validation without duplicate typeid checks. Updates PyNativeMethod to leverage the pyclass ctx parameter mechanism for type context. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (2)
crates/vm/src/object/payload.rs (1)
25-34: Clarify safety docs and contract forvalidate_downcastable_from
downcastable_fromnow performs thetypeidcheck itself and then callsvalidate_downcastable_from. The safety comment (“should only be called ifpayload_type_idmatches the type ofobj”) no longer reflects the actual behavior, and override implementations (likePyUtf8Str) rely on the fact thatvalidate_downcastable_fromis only invoked after thetypeidequality has been verified.To make this extension point safer for future implementors, I suggest:
- Update the doc comment on
downcastable_fromto describe what guarantees it provides (e.g., that it first checksobj.typeid() == Self::payload_type_id()).- Add a brief doc comment on
validate_downcastable_fromstating that, when called viadowncastable_from,objis guaranteed to satisfy thepayload_type_idcheck, and that callers should not invoke it directly without that precondition.This documents the intended use and justifies unsafe downcasts inside overrides like
PyUtf8Str::validate_downcastable_from.crates/vm/src/builtins/str.rs (1)
1935-1939: Unsafe cast inPyUtf8Str::validate_downcastable_fromis sound but deserves a slightly stronger commentThe implementation:
- Overrides
payload_type_id()to returnTypeId::of::<PyStr>().- Relies on
PyPayload::downcastable_fromto checkobj.typeid() == TypeId::of::<PyStr>()before callingvalidate_downcastable_from.- Then performs
unsafe { obj.downcast_unchecked_ref::<PyStr>() }and checksis_utf8().Given this call pattern, the unsafe cast is valid: when
validate_downcastable_fromruns,obj’s payload is guaranteed to be aPyStr, andPyUtf8Strisrepr(transparent)overPyStr.To make the invariant clearer for future changes, consider expanding the comment to mention that:
validate_downcastable_fromis only meant to be called viaPyPayload::downcastable_from, and- the preceding
typeidcheck, together with the overriddenpayload_type_id(), is what justifies usingdowncast_unchecked_ref::<PyStr>()here.Functionally the change looks correct and nicely reuses the new hook to avoid duplicating the type-id logic.
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
crates/vm/src/builtins/builtin_func.rs(1 hunks)crates/vm/src/builtins/str.rs(1 hunks)crates/vm/src/object/payload.rs(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.rs
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.rs: Follow the default rustfmt code style by runningcargo fmtto format Rust code
Always run clippy to lint Rust code (cargo clippy) before completing tasks and fix any warnings or lints introduced by changes
Follow Rust best practices for error handling and memory management
Use the macro system (pyclass,pymodule,pyfunction, etc.) when implementing Python functionality in Rust
Files:
crates/vm/src/object/payload.rscrates/vm/src/builtins/builtin_func.rscrates/vm/src/builtins/str.rs
🧬 Code graph analysis (1)
crates/vm/src/builtins/builtin_func.rs (1)
crates/derive-impl/src/util.rs (1)
base(416-418)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Run snippets and cpython tests (ubuntu-latest)
- GitHub Check: Run snippets and cpython tests (windows-latest)
🔇 Additional comments (1)
crates/vm/src/builtins/builtin_func.rs (1)
151-155:ctx = "builtin_method_type"wiring forPyNativeMethodlooks consistentThe added
ctx = "builtin_method_type"onPyNativeMethodaligns withinit()usingcontext.types.builtin_method_typeand removes the need for a separatePyPayloadimpl to provideclass(ctx). This keeps the type wiring in one place and should preserve behavior for comparisons and calls that rely ondowncast_ref::<PyNativeMethod>(), assuming the pyclass machinery provides the payload impl as expected.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.