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/pyerrors.rs`:
- Around line 138-145: Replace all use of expect!/panic!/assert! in the FFI
entrypoints so they fail gracefully through the Python/C-API: validate C string
UTF-8 in PyErr_SetString and on error create and set a Python Unicode/ValueError
via the VM and return the C-API sentinel value for that function; check for
missing exception types in PyErr_PrintEx and PyErr_WriteUnraisable and on
failure set an appropriate Python exception and return early; handle downcast
failures in PyErr_DisplayException by setting a TypeError and returning the
function's sentinel; and in PyErr_NewException replace expect/panic/assert with
input validation that sets a Python exception (TypeError/ValueError) via the VM
and returns NULL or the proper error sentinel. Locate and update the functions
named PyErr_SetString, PyErr_PrintEx, PyErr_DisplayException,
PyErr_WriteUnraisable, and PyErr_NewException to perform these checks and use
the VM to set exception state instead of aborting.
- Around line 99-105: PyErr_Occurred is returning the exception instance instead
of the exception type; change the mapping inside PyErr_Occurred to return the
exception's type object pointer rather than exc.as_object().as_raw(). Locate the
closure in the PyErr_Occurred function that calls vm.current_exception() and
replace the mapping to use the exception's class/type accessor (e.g.,
exc.class().as_object().as_raw() or the equivalent method that returns the
exception type object) while keeping the unwrap_or_default fallback.
- Around line 118-123: PyErr_SetRaisedException currently invokes undefined
behavior by calling NonNull::new_unchecked(exc) when exc can be NULL; change the
handling to use NonNull::new(exc) and branch on the Option: if NULL then clear
the VM error indicator (return Ok or equivalent) otherwise construct the
PyObjectRef via PyObjectRef::from_raw(...) and downcast_unchecked as before and
return Err(exception). Ensure you update the closure passed to with_vm to handle
the None case (clear/ok) and the Some(nonnull) case to build and return the
Err(exception).

In `@crates/capi/src/util.rs`:
- Around line 79-84: The impl of FfiResult for usize currently does an unchecked
cast in into_output, which can silently overflow; update into_output on the
usize impl to perform a checked conversion to isize (compare self to isize::MAX
or use try_from) and return ERR_VALUE if it would overflow while also setting a
Python exception on the provided VirtualMachine (use the VM API to raise an
OverflowError or ValueError), otherwise return the safely-cast isize; keep
ERR_VALUE as -1 and only use it when an exception was set.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Duplicate comments:
In `@crates/capi/src/util.rs`:
- Around line 79-85: The impl FfiResult<isize> for usize currently panics in
into_output via expect; change it to handle overflow by attempting
self.try_into() and, on Err, call the VM overflow-error path and return the
ERR_VALUE sentinel instead of panicking. Concretely, update into_output to match
on self.try_into(): on Ok(v) return v, on Err(_) create/obtain an overflow
exception via VirtualMachine (e.g. new_overflow_error or the project's overflow
constructor) and set it on the vm (vm.set_exception(...) or the project's
equivalent), then return Self::ERR_VALUE; keep the FfiResult trait, into_output
function name, ERR_VALUE constant and VirtualMachine reference to locate the
change.

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 70-80: The extern "C" function Py_GetConstantBorrowed currently
panics on invalid constant_id which will abort the process; update the match
default arm to return a NULL pointer instead of calling panic!. Inside the
with_vm closure (using vm and ctx), replace the _ => panic!(...) branch with a
branch that returns std::ptr::null_mut() (a *mut PyObject) so the C API gets
NULL for invalid args; ensure the match arms all yield the same *mut PyObject
type and remove the panic invocation.

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 @.github/workflows/ci.yaml:
- Around line 119-123: The `if` condition on the "run c-api tests" step
incorrectly checks for 'windows-2025'; update the condition `if: runner.os !=
'windows-2025'` to use the actual runner OS value `if: runner.os != 'Windows'`
so the step skips on Windows runners (match the existing pattern used elsewhere
in the file).

In `@crates/capi/src/object.rs`:
- Around line 39-66: The code casts ty.slots.flags.bits() (u64) to c_ulong which
is 32-bit on MSVC, causing truncation of internal flags (e.g.
HAS_DICT/HAS_WEAKREF at bits 40/41); fix by masking and asserting: compute let
raw = ty.slots.flags.bits(); debug_assert_eq!(raw & !0xffff_ffff, 0, "unexpected
high bits set (HAS_DICT/HAS_WEAKREF)"); let flags = (raw & 0xffff_ffff) as
c_ulong; return that—this ensures consistent behavior across platforms and makes
unintended high-bit use detectable; update the code around where flags is built
(references: ty.slots.flags.bits(), PY_TPFLAGS_* constants,
HAS_DICT/HAS_WEAKREF).

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 @.github/workflows/ci.yaml:
- Line 115: The CI workflow currently hardcodes "--exclude rustpython-capi" into
the cargo test command instead of adding it to the shared env variable, causing
clippy to still include that crate on Windows; update the WORKSPACE_EXCLUDES
environment variable to include "rustpython-capi" (so it is respected by all
jobs) and remove the inline "--exclude rustpython-capi" from the cargo test
invocation (the line containing "run: cargo test --workspace --exclude
rustpython-capi ...") so tests and the clippy job both consume ${{
env.WORKSPACE_EXCLUDES }} consistently; also verify the clippy command that uses
${{ env.WORKSPACE_EXCLUDES }} remains unchanged.

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/pystate.rs`:
- Around line 50-51: The current stubs PyEval_SaveThread and
PyEval_RestoreThread must be implemented to bridge RustPython's threading API to
the C-API: change PyEval_SaveThread (signature returning *mut PyThreadState) to
call the equivalent of releasing the GIL (use
allow_threads()/release_current_thread() semantics) and return a pointer-sized
token representing the saved thread state (PyThreadState) that can later be
used; implement PyEval_RestoreThread to accept that token and re-acquire/restore
the thread state by calling the attach/re-acquire logic
(attach_current_thread()/acquire GIL) using the passed PyThreadState token.
Ensure both functions reference the exact symbols PyEval_SaveThread,
PyEval_RestoreThread and type PyThreadState so C extensions using
Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS get correct GIL release/restore
behavior.

---

Duplicate comments:
In `@crates/capi/src/pyerrors.rs`:
- Around line 195-239: PyErr_NewException and PyErr_NewExceptionWithDoc
currently panic/expect on bad inputs, ignore the _doc arg, and assert on a
non-null dict; change them to validate inputs and fail via the C-API error path
(return null pointer after setting a Python exception) instead of panicking.
Specifically: in PyErr_NewException, replace the CStr::to_str()/rsplit_once and
base parsing expect/panic paths with graceful checks that set an appropriate vm
exception and return std::ptr::null_mut() on error; accept a non-null dict by
using it to populate the new type’s dict (instead of assert!), and when base is
NULL treat it as using the default base per CPython semantics or validate tuple
contents and error out cleanly. In PyErr_NewExceptionWithDoc, forward
name/base/dict but use the non-NULL _doc to set the new type’s __doc__ (convert
C string safely and set an error/return null on failure) before returning the
new exception type created by vm.ctx.new_exception_type. Ensure all error paths
use the VM/C-API error-setting mechanism rather than panic!/expect! and return
null pointers on failure.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@crates/capi/src/object.rs`:
- Around line 14-21: The Py_IS_TYPE function unnecessarily wraps the class
pointer comparison in with_vm while Py_TYPE accesses op.class() directly; if
obj.class().is(ty) does not require VM state, remove the with_vm wrapper and
mirror Py_TYPE’s pattern (use unsafe deref of op and ty and call
obj.class().is(ty) directly) so the behavior and calling convention are
consistent; if the is() path actually needs VM context, instead keep with_vm but
add a brief inline comment on why Py_IS_TYPE requires VM state while Py_TYPE
does not.

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 `@Cargo.toml`:
- Line 106: The Cargo.toml currently references pyo3 and pyo3-ffi as unpinned
git dependencies which breaks reproducible builds; update both pyo3 and pyo3-ffi
entries in Cargo.toml to pin them to the known-good commit
901b032bfb8ec8eb05b39be3b98ef880427cf15a by adding the git URL and rev (or tag)
fields for each dependency so Cargo always fetches that commit (ensure you
update both the pyo3 and pyo3-ffi dependency entries).