Add basic pyobject c-api functions#7872
Merged
Merged
Conversation
Contributor
📝 WalkthroughWalkthroughThis PR expands RustPython's C-API surface with seven new ChangesObject C-API Functions
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/capi/src/object.rs`:
- Around line 87-89: The code currently uses
CStr::from_ptr(attr_name).to_str().expect(...) which will panic on invalid
UTF-8; instead decode the C string and handle errors by converting the UTF-8
error into a Python exception and returning the appropriate error indicator
(e.g., null pointer or error code) from the surrounding FFI function. Replace
the .expect() on to_str() with a match or map_err that calls the Python C-API to
set an exception (e.g., PyErr_SetString(PyExc_UnicodeDecodeError, ... ) or the
project's helper for raising Python errors), include the invalid data/error
message, and then return early from the function using the function's error
return convention; update uses of the local variable name accordingly after
successful decoding.
- Around line 70-74: The code currently calls
CStr::from_ptr(attr_name).to_str().expect(...), which will panic on invalid
UTF-8; replace the expect with explicit error handling by matching the Result
from to_str(): on Ok(s) assign s to name, on Err(e) set a Python exception (e.g.
PyErr_SetString(PyExc_ValueError, format!("invalid UTF-8 in attribute name: {}",
e).as_ptr()) or using pyo3::exceptions::PyValueError::new_err(...)) and return
the function's error sentinel (NULL for pointer returns or -1 for int returns).
Update the block around CStr::from_ptr(attr_name) / to_str() to use match or
map_err so attr_name decoding never panics and the function returns a
Python-level error instead; reference the variables/functions attr_name, name,
CStr::from_ptr and to_str when making the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: f82b4ad9-daf1-4860-9a13-70f1be3e791c
📒 Files selected for processing (1)
crates/capi/src/object.rs
Comment on lines
+70
to
+74
| let name = unsafe { | ||
| CStr::from_ptr(attr_name) | ||
| .to_str() | ||
| .expect("attribute name must be valid UTF-8") | ||
| }; |
Contributor
There was a problem hiding this comment.
Replace .expect() with proper error handling to avoid panics.
The .expect() call will panic if attr_name contains invalid UTF-8, crashing the entire process. In C APIs, panics cannot be caught by C callers. Instead, convert UTF-8 errors to Python exceptions.
🛡️ Proposed fix to handle UTF-8 decode errors gracefully
let obj = unsafe { &*obj };
- let name = unsafe {
- CStr::from_ptr(attr_name)
- .to_str()
- .expect("attribute name must be valid UTF-8")
- };
+ let name = unsafe { CStr::from_ptr(attr_name) }
+ .to_str()
+ .map_err(|_| vm.new_unicode_decode_error("attribute name must be valid UTF-8".to_owned()))?;
obj.get_attr(name, vm)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@crates/capi/src/object.rs` around lines 70 - 74, The code currently calls
CStr::from_ptr(attr_name).to_str().expect(...), which will panic on invalid
UTF-8; replace the expect with explicit error handling by matching the Result
from to_str(): on Ok(s) assign s to name, on Err(e) set a Python exception (e.g.
PyErr_SetString(PyExc_ValueError, format!("invalid UTF-8 in attribute name: {}",
e).as_ptr()) or using pyo3::exceptions::PyValueError::new_err(...)) and return
the function's error sentinel (NULL for pointer returns or -1 for int returns).
Update the block around CStr::from_ptr(attr_name) / to_str() to use match or
map_err so attr_name decoding never panics and the function returns a
Python-level error instead; reference the variables/functions attr_name, name,
CStr::from_ptr and to_str when making the change.
Comment on lines
+87
to
+89
| let name = unsafe { CStr::from_ptr(attr_name) } | ||
| .to_str() | ||
| .expect("attribute name must be valid UTF-8"); |
Contributor
There was a problem hiding this comment.
Replace .expect() with proper error handling to avoid panics.
Same issue as in PyObject_GetAttrString: the .expect() call will panic on invalid UTF-8, crashing the process. Convert UTF-8 errors to Python exceptions instead.
🛡️ Proposed fix to handle UTF-8 decode errors gracefully
let obj = unsafe { &*obj };
- let name = unsafe { CStr::from_ptr(attr_name) }
- .to_str()
- .expect("attribute name must be valid UTF-8");
+ let name = unsafe { CStr::from_ptr(attr_name) }
+ .to_str()
+ .map_err(|_| vm.new_unicode_decode_error("attribute name must be valid UTF-8".to_owned()))?;
let value = unsafe { &*value }.to_owned();🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@crates/capi/src/object.rs` around lines 87 - 89, The code currently uses
CStr::from_ptr(attr_name).to_str().expect(...) which will panic on invalid
UTF-8; instead decode the C string and handle errors by converting the UTF-8
error into a Python exception and returning the appropriate error indicator
(e.g., null pointer or error code) from the surrounding FFI function. Replace
the .expect() on to_str() with a match or map_err that calls the Python C-API to
set an exception (e.g., PyErr_SetString(PyExc_UnicodeDecodeError, ... ) or the
project's helper for raising Python errors), include the invalid data/error
message, and then return early from the function using the function's error
return convention; update uses of the local variable name accordingly after
successful decoding.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit