Reviewing files that changed from the base of the PR and between 21300f6 and 666979e.

• crates/derive-impl/src/pyclass.rs (8 hunks)
• crates/derive-impl/src/pystructseq.rs (2 hunks)
• crates/stdlib/src/socket.rs (4 hunks)
• crates/stdlib/src/ssl.rs (20 hunks)
• crates/stdlib/src/ssl/compat.rs (5 hunks)
• crates/vm/src/builtins/bool.rs (4 hunks)
• crates/vm/src/builtins/int.rs (1 hunks)
• crates/vm/src/class.rs (1 hunks)
• crates/vm/src/exception_group.rs (1 hunks)
• crates/vm/src/exceptions.rs (13 hunks)
• crates/vm/src/object/core.rs (2 hunks)
• crates/vm/src/object/payload.rs (3 hunks)
• crates/vm/src/stdlib/ast/pyast.rs (14 hunks)
• crates/vm/src/stdlib/ctypes.rs (3 hunks)
• crates/vm/src/stdlib/ctypes/array.rs (8 hunks)
• crates/vm/src/stdlib/ctypes/base.rs (4 hunks)
• crates/vm/src/stdlib/ctypes/field.rs (1 hunks)
• crates/vm/src/stdlib/ctypes/function.rs (6 hunks)
• crates/vm/src/stdlib/ctypes/pointer.rs (7 hunks)
• crates/vm/src/stdlib/ctypes/structure.rs (6 hunks)
• crates/vm/src/stdlib/ctypes/union.rs (6 hunks)
• crates/vm/src/stdlib/io.rs (22 hunks)
• crates/vm/src/stdlib/os.rs (1 hunks)
• crates/vm/src/types/structseq.rs (1 hunks)
• crates/vm/src/vm/context.rs (7 hunks)
• crates/vm/src/vm/vm_new.rs (3 hunks)
• extra_tests/snippets/stdlib_ctypes.py (1 hunks)

• GitHub Check: Run snippets and cpython tests (windows-latest)

crates/vm/src/types/structseq.rs (1)

192-192: Good improvement: expect() with descriptive message.

Replacing .unwrap() with .expect() and providing a clear error message is a best practice that improves debuggability. The message correctly identifies this as an internal RustPython bug, which helps with triage if this invariant is ever violated.

crates/vm/src/exception_group.rs (1)

47-50: LGTM! Wrapper pattern aligns with the new subclass layout.

The transition from a unit struct to a #[repr(transparent)] newtype wrapper around PyBaseException is consistent with the broader refactor. This enables proper base-class relationships while maintaining memory layout compatibility for safe casting.

crates/vm/src/object/payload.rs (1)

19-26: LGTM! Cold path helper for error generation.

The #[cold] annotation is appropriate for an error path that should rarely execute, helping branch prediction optimization.

crates/vm/src/vm/context.rs (5)

35-36: LGTM! Type change aligns with PyBool wrapper pattern.

Changing true_value and false_value from PyIntRef to PyRef<PyBool> correctly reflects the new type hierarchy where PyBool is a proper wrapper around PyInt.

---

282-285: LGTM! Simplified trait bound.

Removing the redundant PyPayload bound is correct since PyObjectPayload already requires it (as shown at line 141).

---

306-307: LGTM! Boolean singleton creation with wrapper pattern.

Creating PyBool(PyInt::from(1)) and PyBool(PyInt::from(0)) correctly establishes the boolean singletons using the new wrapper structure.

---

450-456: LGTM! Return type correctly updated.

The method now returns PyRef<PyBool> matching the updated field types, maintaining the singleton pattern for boolean values.

---

510-520: No changes needed — basicsize: 0 is appropriate for heap exception types.

The explicit basicsize: 0 in the PyTypeSlots is correctly handled by PyType::new_heap_inner, which automatically inherits the base class basicsize when it's set to 0 (lines 327-329 in crates/vm/src/builtins/type.rs). This ensures that by the time into_ref_with_type is called, both the exact exception class and the dynamically created exception type have matching basicsize values, preventing any size mismatch errors. This design is safe and consistent with how other heap types (like ExceptionGroup in exception_group.rs) are created.

crates/vm/src/stdlib/ast/pyast.rs (2)

6-79: LGTM! Macro updated for wrapper-based AST nodes.

The impl_node macro correctly generates #[repr(transparent)] wrapper structs with the base type, aligning with the new subclass payload layout. The pattern matching and recursive macro invocations are consistent across all arms.

---

81-82: LGTM! Base AST node types converted to wrapper pattern.

All intermediate AST base types (NodeMod, NodeStmt, NodeExpr, etc.) correctly use #[repr(transparent)] wrappers around NodeAst, establishing the proper type hierarchy for AST nodes.

crates/vm/src/builtins/int.rs (1)

256-263: LGTM! Proper use of upcast for bool subclass.

The .upcast() call correctly converts PyRef<PyBool> to PyRef<PyInt>, leveraging the new PySubclass trait to maintain type safety while allowing with_value to return a consistent PyRef<Self> type.

crates/vm/src/class.rs (1)

174-188: Clean trait design for subclass relationships.

The PySubclass trait provides a clear abstraction for base-class access. The documentation accurately describes the auto-implementation by #[pyclass] and the #[repr(transparent)] requirement for ownership transfer.

crates/derive-impl/src/pystructseq.rs (1)

448-513: Well-structured newtype wrapper implementation.

The generated code correctly:

1. Uses #[repr(transparent)] for safe memory layout
2. Delegates payload_type_id() to PyTuple for proper type identification
3. Implements validate_downcastable_from using fast_issubclass for correct subtype checking
4. Provides PySubclass implementation for base access

This aligns well with the PR's subclass payload layout goals.

crates/stdlib/src/ssl/compat.rs (2)

225-256: Consistent error construction with OS subtype pattern.

The changes correctly use vm.new_os_subtype_error() followed by .upcast() to return PyBaseExceptionRef. This pattern is consistently applied across all SSL error creation functions and aligns with the PR's exception handling refactoring.

---

546-561: Error conversion paths properly upcast to base exception type.

All SslError variants that create OS-subtype errors (WantRead, WantWrite, Timeout, ZeroReturn, Eof) correctly call .upcast() to convert from PyRef<PyOSError> to PyBaseExceptionRef.

crates/vm/src/stdlib/ctypes/pointer.rs (2)

12-14: Proper repr(transparent) wrapper for type object.

The #[repr(transparent)] attribute on PyCPointerType(PyType) ensures correct memory layout for the type wrapper pattern used throughout this PR.

---

64-68: No action needed—empty base initialization is correct for pointer types.

Pointer types intentionally use CDataObject::from_bytes(vec![], None) because they store their data in a separate contents field rather than in the CData buffer. In contrast, structures and unions (which store binary field data) use from_stg_info with properly sized buffers. This design is consistent across all pointer-like types (PyCPointer, PyCFuncPtr) and is architecturally sound.

crates/vm/src/stdlib/ctypes/field.rs (1)

10-16: The removal of PyPayload derive from PyCFieldType is correct. PyCFieldType is a metaclass (type) for field descriptors, not a payload-bearing instance class. Metaclass types with #[pyclass(base = PyType)] do not require PyPayload implementation. The actual field descriptor class PyCField correctly derives PyPayload. This pattern is consistent across all ctypes metaclasses (PyCStructType, PyCPointerType, PyCArrayType, etc.), which also use base = PyType without PyPayload derive.

crates/vm/src/stdlib/ctypes.rs (2)

18-18: LGTM: Public export expanded correctly.

Adding CDataObject to the public exports is consistent with the new base pattern introduced across ctypes types.

---

50-50: LGTM: Import aligned with construction changes.

The expanded import correctly brings in CDataObject and PyCData for use in new_simple_type.

crates/vm/src/vm/vm_new.rs (4)

96-99: Debug assertion may fail for user-defined exception types.

The debug_assert_eq! checks that exc_type.slots.basicsize equals size_of::<PyBaseException>(). Per the docstring, this function "should only be used with builtin exception types," but the assertion will panic in debug builds if misused. This is good for catching errors early, though consider adding a comment clarifying why this assertion exists.

---

109-141: LGTM: Well-structured OS error construction.

The new new_os_error and new_os_subtype_error methods properly handle OSError construction with optional errno. The nested new_os_subtype_error_impl function keeps the implementation contained, though it could be a private method if reused elsewhere.

One minor note: the .expect("new_os_error usage error") calls will panic on construction failure. This is acceptable for internal API misuse, but ensure callers pass valid exception types.

---

120-120: Debug assertion validates PyOSError construction.

This assertion ensures exc_type has the correct basicsize for PyOSError, which is essential for the new subclass payload layout. Good defensive programming.

---

259-264: LGTM: Errno-based error construction correctly delegates.

The updated new_errno_error properly maps errno to a specific exception subtype via errno_to_exc_type, falling back to os_error if no mapping exists, then delegates to new_os_subtype_error.

crates/vm/src/stdlib/ctypes/base.rs (4)

222-228: LGTM: Simple and effective constructor.

The PyCData::new constructor provides a clean way to wrap a CDataObject in a PyRwLock, supporting the new base pattern across ctypes types. Based on coding guidelines, this follows the macro system pattern appropriately.

---

424-428: New _base field establishes base-class relationship.

Adding _base: PyCData alongside cdata: PyRwLock<CDataObject> is consistent with the PR's goal of formalizing subclass-base relationships. The pyclass declaration correctly specifies base = PyCData.

---

659-664: Same clone pattern as other ctypes types.

The constructor creates a CDataObject and clones it for both _base and cdata fields. This is consistent with the pattern in new_simple_type and other ctypes types. The duplication concern raised earlier applies here as well.

---

238-241: The #[repr(transparent)] usage is correct and follows the established pattern.

All other metaclass types in ctypes (PyCStructType, PyCPointerType, PyCUnionType, PyCArrayType) use the same #[repr(transparent)] attribute with identical structure. This confirms that PyCSimpleType correctly maintains memory layout compatibility with PyType and is consistent with the codebase's metaclass design.

crates/vm/src/stdlib/ctypes/function.rs (3)

7-7: LGTM: Import added for CDataObject usage.

The import is required for initializing the _base field in PyCFuncPtr constructors.

---

164-176: LGTM: _base field added to PyCFuncPtr.

The new _base: PyCData field is correctly placed at the beginning of the struct, consistent with the base-class pattern across ctypes types. The struct maintains all existing fields.

---

197-197: Consistent _base initialization across all constructor paths.

All four constructor branches (empty args, integer address, tuple form, callable form) correctly initialize _base with PyCData::new(CDataObject::from_bytes(vec![], None)). Using an empty buffer is appropriate for function pointers since they don't store data like other ctypes types.

crates/vm/src/stdlib/ctypes/structure.rs (6)

18-20: Consistent transparent wrapper pattern for metaclass.

PyCStructType(PyType) with #[repr(transparent)] follows the same pattern as PyCSimpleType, ensuring consistent metaclass handling across ctypes types.

---

222-229: LGTM: _base field added to PyCStructure.

The structure correctly adds _base: PyCData while maintaining the existing cdata and fields fields. This aligns with the PR's goal of enabling more specific subclass-typed function parameters.

---

299-304: Consistent initialization pattern in slot_new.

Creates CDataObject from StgInfo, then clones for both _base and cdata. Consistent with other ctypes types.

---

370-377: LGTM: from_address correctly updated.

The from_address method properly initializes both _base and cdata from the same CDataObject.

---

423-430: Good: from_buffer preserves source reference.

The from_buffer method correctly passes Some(source) to CDataObject::from_bytes, which stores the reference in objects to keep the source buffer alive. This is important for memory safety when the structure references external buffer data.

---

468-475: LGTM: from_buffer_copy creates independent copy.

Unlike from_buffer, from_buffer_copy correctly passes None since it creates an independent copy of the data, not a reference to the source buffer.

crates/derive-impl/src/pyclass.rs (5)

308-361: Well-structured base field validation.

The validate_base_field function properly validates that when a base class is specified, the struct has the base type as its first field. This is essential for #[repr(transparent)] to work correctly and ensures proper memory layout for subclassing.

One minor observation: the error messages are clear and informative, providing the expected base type name.

---

431-449: LGTM: repr(transparent) detection and basicsize computation.

The logic correctly detects #[repr(transparent)] and sets basicsize to 0 when the type has a base class with transparent representation, ensuring the type shares the same memory layout as its base.

---

611-652: PyPayload generation for base types looks correct.

The conditional logic properly handles:

1. Types with a base: forwards payload_type_id to the base and adds validate_downcastable_from check
2. Types without a base but with a ctx type: generates simple class resolution
3. Types without base or ctx: no additional impl needed

The #[allow(clippy::collapsible_else_if)] is appropriate here for readability.

---

1212-1213: Clarifying comment for cfg matching is helpful.

The added comment explains that getter and setter must have matching #[cfg] attributes since they're paired by the map key (name, cfgs).

---

485-502: Remove the comment addition and close as not an issue.

The generated PySubclass impl correctly assumes a tuple struct layout. The impl is only generated when is_repr_transparent is true, and Rust's #[repr(transparent)] attribute guarantees exactly one field. This field must be the base type (validated by validate_base_field), so accessing it via &self.0 is always correct, whether the struct uses named or unnamed field syntax. The validate_base_field function handles both cases to provide flexible validation, but the actual PySubclass impl generation is safely gated by the is_repr_transparent check, which ensures the memory layout assumption holds.

crates/vm/src/builtins/bool.rs (3)

21-34: TryFromBorrowedObject accepts any integer as a boolean.

The implementation now downcasts to PyInt and treats any non-zero integer as true. This differs from strict boolean checking and aligns with Python's truthy semantics for integers. However, this means bool.try_from_borrowed_object will accept plain integers, not just booleans.

Verify this is the intended behavior - if callers expect only actual bool objects, this could be a semantic change.

---

88-96: LGTM: PyBool as transparent wrapper around PyInt.

The #[repr(transparent)] ensures PyBool has the same memory layout as PyInt, which is correct for the subclass pattern. The ctx = "bool_type" and base = PyInt attributes properly wire up the class hierarchy.

The Debug implementation correctly extracts the boolean value from the inner PyInt.

---

222-228: No action needed—all call sites include proper type checks.

The get_value function is safe despite the .unwrap(). All callers verify the object is a PyBool before calling: external callers in py_serde.rs (line 70) and jit.rs (line 141) use fast_isinstance or cls.is() checks, and internal calls within bool.rs occur in bool-specific methods protected by type guards (e.g., lines 136–137 in __or__ check fast_isinstance(vm.ctx.types.bool_type) for both operands). The function is pub(crate) scoped and never receives non-PyBool objects in practice.

Likely an incorrect or invalid review comment.

crates/vm/src/stdlib/ctypes/union.rs (1)

14-18: LGTM: PyCUnionType as transparent wrapper around PyType.

The metaclass is correctly defined as a transparent wrapper, consistent with the new subclass pattern.

crates/stdlib/src/socket.rs (4)

18-18: LGTM: PyOSError added to imports.

The import aligns with the new error handling pattern that uses PyOSError directly.

---

1829-1833: LGTM: From implementation for PyRef.

The implementation correctly upcasts PyRef<PyOSError> to PyBaseExceptionRef for integration with the IoOrPyException enum.

---

1852-1852: LGTM: Timeout error upcast.

The .upcast() call correctly converts PyRef<PyOSError> to the expected PyBaseExceptionRef type.

---

2420-2428: LGTM: OS subtype error creation and timeout functions.

The changes consistently use vm.new_os_subtype_error to create properly typed OS exceptions. The function signatures now return PyRef<PyOSError>, which provides better type safety.

crates/vm/src/stdlib/ctypes/array.rs (2)

26-28: LGTM: PyCArrayType as transparent wrapper around PyType.

Consistent with the new subclass pattern used throughout the codebase.

---

162-172: Verify unsafe raw pointer read from symbol address.

The code reads data from a symbol address obtained from a shared library. While there's a null check, verify that:

1. The symbol address points to valid readable memory of the expected size
2. The symbol data remains valid for the lifetime of the PyCArray instance (the dll reference helps, but data could still be modified)

crates/stdlib/src/ssl.rs (4)

346-410: LGTM: Exception type restructuring follows newtype wrapper pattern correctly.

The transparent newtype wrappers around base exception types (PySSLError wrapping PyOSError, subclasses wrapping PySSLError) align with the PR's goal of enabling more specific subclass-typed parameters. The __str__ implementation correctly preserves OSError-compatible behavior by checking for strerror attribute first.

---

1236-1242: LGTM: Error construction follows OS-subtype pattern.

The password decryption error correctly uses new_os_subtype_error with None errno (since this is an SSL/crypto error, not a system error) and calls upcast() to convert to the expected exception type.

---

1870-1880: LGTM: FileNotFoundError construction is correct.

The error correctly sets errno to 2 (ENOENT), creates the FileNotFoundError subtype, sets the filename attribute, and calls upcast(). This matches CPython's FileNotFoundError behavior.

---

3347-3353: LGTM: Error construction in read/write operations is consistent.

The shutdown, EOF, and operation errors correctly use the OS-subtype error pattern with appropriate errno values (None for protocol errors) and descriptive messages. The use of helper functions with .upcast() properly converts between exception types.

Also applies to: 3400-3406, 3478-3484

crates/vm/src/stdlib/io.rs (7)

83-98: Module wiring via _io::unsupported_operation() looks fine.
Pulling the type via _io::unsupported_operation() and exporting it (Line 91-95) is a nice cleanup over ad-hoc statics.

---

148-156: Import tweak is fine.
Switching to PyBool (Line 152) matches the new more-specific return types in this PR.

---

205-208: new_unsupported_operation() integration looks good.
Creating an OSError subtype with the centralized UnsupportedOperation type (Line 205-208) is consistent with the refactor direction.

---

426-462: _IOBase.__closed type change is OK; just ensure it matches Python-visible expectations.
Returning PyRef<PyBool> (Line 459-461) aligns with the “more specific subclass-typed parameters” goal; worth running stdlib _io behavioral tests around closed/__closed since this is a core attribute.

---

640-645: Transparent base wrappers are a good approach for the new layout.
The #[repr(transparent)] wrappers for _RawIOBase, _BufferedIOBase, _TextIOBase plus Default (Line 640-645, 700-705, 764-770) look consistent with the subclass payload embedding strategy.

Also applies to: 700-705, 764-770

---

1766-2032: Embedded _base fields: looks consistent; please clippy/test for any accidental default-constructed “uninitialized” states.
The _base: <BaseType> pattern across buffered/text/raw/file IO types (Line 1766-2032, 2376-2383, 3657-3695, 3802-3827, 4441-4474) matches the PR objective. Main risk is behavior of any Default/DefaultConstructor paths that could create instances without the expected init invariants (e.g., mutex state, “uninitialized object” errors) — worth validating constructors and __init__ flows still gate operations properly.

Also applies to: 2376-2383, 3657-3695, 3802-3827, 4441-4474

---

4246-4268: unsupported_operation() is correctly implemented. RustPython is a single-context architecture where all VirtualMachine instances share the same global Context::genesis(). The static cell pattern here is safe and intentional—there is no scenario with multiple independent contexts. The concern about multi-context support does not apply to this codebase.

crates/vm/src/exceptions.rs (6)

966-969: extend_exception!(PyOSError, ...) change is fine.
Removing dynamic attributes in favor of struct fields + getsets matches the refactor.

---

1196-1210: Types-module import adjustments look fine.
No concerns with the added imports to support the new PyOSError implementation.

---

1235-1437: #[repr(transparent)] wrapper migration looks consistent; just ensure subclass/base expectations are tested.
The broad conversion of exception types into transparent wrappers matches the new subclass payload design and should enable more precise typed refs.

Also applies to: 1736-2202

---

1682-1734: Field getsets look good; nice use of swap_to_temporary_refs.
The getters/setters for errno/strerror/filename/filename2(/winerror) are straightforward and align with the new field-backed model.

---

1-341: Process: please run formatting + clippy on this PR.
Given the scale of unsafe and layout changes, it’s worth ensuring cargo fmt + cargo clippy are clean and that exception/stdlib test suites cover the new constructor + pickle/GC paths.

---

1487-1521: Non-Windows filename2 handling appears incorrect (len==4 should populate filename2).

In py_new, filename2 is only set when len == 5 (Line 1500-1504). On non-Windows, the 4th positional arg is typically filename2, so this loses data. Similar issue in slot_init where filename2 is only set on len == 5 (Line 1591-1593).

Suggested fix (platform-specific indexing):

@@
-            let filename2 = if len == 5 {
-                args.args.get(4).cloned()
-            } else {
-                None
-            };
+            #[cfg(windows)]
+            let filename2 = if len == 5 { args.args.get(4).cloned() } else { None };
+            #[cfg(not(windows))]
+            let filename2 = if len == 4 { args.args.get(3).cloned() } else { None };
@@
-                if len == 5 {
-                    let _ = unsafe { exc.filename2.swap(new_args.args.get(4).cloned()) };
-                }
+                #[cfg(windows)]
+                if len == 5 {
+                    exc.filename2
+                        .swap_to_temporary_refs(new_args.args.get(4).cloned(), vm);
+                }
+                #[cfg(not(windows))]
+                if len == 4 {
+                    exc.filename2
+                        .swap_to_temporary_refs(new_args.args.get(3).cloned(), vm);
+                }

Also applies to: 1551-1601

⛔ Skipped due to learnings

Learnt from: youknowone
Repo: RustPython/RustPython PR: 6358
File: crates/vm/src/exception_group.rs:173-185
Timestamp: 2025-12-09T08:46:58.660Z
Learning: In crates/vm/src/exception_group.rs, the derive() method intentionally always creates a BaseExceptionGroup instance rather than preserving the original exception class type. This is a deliberate design decision that differs from CPython's behavior.

Reviewing files that changed from the base of the PR and between 666979e and 941b373.

• crates/derive-impl/src/pyclass.rs (8 hunks)
• crates/derive-impl/src/pystructseq.rs (2 hunks)
• crates/stdlib/src/socket.rs (4 hunks)
• crates/stdlib/src/ssl.rs (20 hunks)
• crates/stdlib/src/ssl/compat.rs (5 hunks)
• crates/vm/src/builtins/bool.rs (4 hunks)
• crates/vm/src/builtins/int.rs (1 hunks)
• crates/vm/src/class.rs (1 hunks)
• crates/vm/src/exception_group.rs (1 hunks)
• crates/vm/src/exceptions.rs (13 hunks)
• crates/vm/src/object/core.rs (2 hunks)
• crates/vm/src/object/payload.rs (3 hunks)
• crates/vm/src/stdlib/ast/pyast.rs (14 hunks)
• crates/vm/src/stdlib/ctypes.rs (3 hunks)
• crates/vm/src/stdlib/ctypes/array.rs (8 hunks)
• crates/vm/src/stdlib/ctypes/base.rs (4 hunks)
• crates/vm/src/stdlib/ctypes/field.rs (1 hunks)
• crates/vm/src/stdlib/ctypes/function.rs (6 hunks)
• crates/vm/src/stdlib/ctypes/pointer.rs (7 hunks)
• crates/vm/src/stdlib/ctypes/structure.rs (6 hunks)
• crates/vm/src/stdlib/ctypes/union.rs (6 hunks)
• crates/vm/src/stdlib/io.rs (22 hunks)
• crates/vm/src/stdlib/os.rs (1 hunks)
• crates/vm/src/types/structseq.rs (1 hunks)
• crates/vm/src/vm/context.rs (7 hunks)
• crates/vm/src/vm/vm_new.rs (3 hunks)
• extra_tests/snippets/stdlib_ctypes.py (1 hunks)

• crates/vm/src/stdlib/os.rs
• crates/vm/src/class.rs
• crates/stdlib/src/ssl/compat.rs
• crates/vm/src/stdlib/ctypes.rs
• extra_tests/snippets/stdlib_ctypes.py
• crates/vm/src/exception_group.rs
• crates/vm/src/stdlib/ctypes/field.rs
• crates/vm/src/builtins/int.rs
• crates/vm/src/stdlib/ctypes/function.rs

• GitHub Check: Run rust tests (windows-latest)
• GitHub Check: Run tests under miri
• GitHub Check: Run snippets and cpython tests (macos-latest)
• GitHub Check: Run rust tests (macos-latest)
• GitHub Check: Run snippets and cpython tests (windows-latest)
• GitHub Check: Check Rust code with clippy
• GitHub Check: Ensure compilation on various targets

crates/derive-impl/src/pyclass.rs (2)

718-729: Good: stop scanning with(...) once Constructor is found.
This reduces wasted work and matches the intent expressed in prior review.

---

611-638: Verify the semantic intent of the BASICSIZE check for repr(transparent) wrappers.

The size/subclass check is sound, but for #[repr(transparent)] types with base=, the BASICSIZE validation effectively becomes a no-op: the macro generates BASICSIZE = 0 (since the wrapper has identical layout to its base), and at runtime slots.basicsize is automatically inherited to match the base's size. This means the check BASICSIZE <= obj.class().slots.basicsize becomes 0 <= base_size, which always passes.

This design is correct—BASICSIZE = 0 semantically signals "no additional payload"—but confirm that:

1. The size check isn't intended as a safety guard against under-allocated objects (since it's effectively always-true for repr(transparent))
2. The actual validation responsibility falls entirely to the fast_issubclass() call for these types
3. All code paths that construct repr(transparent) types correctly inherit slots.basicsize from their base

crates/vm/src/stdlib/ast/pyast.rs (1)

6-16: Macro wrapper layout looks correct for the new base-first-field scheme.
The generated #[repr(transparent)] struct $name($base); is consistent with the base-field validation and PySubclass expectations.

crates/vm/src/object/payload.rs (2)

19-26: Good refactor: central cold_downcast_type_error() improves call-site clarity.

Also applies to: 50-52

---

102-121: Good safety check: reject subclass construction when basicsize differs.
This closes a class of “valid subtype but incompatible payload layout” issues and provides a clear error.

crates/vm/src/stdlib/ctypes/pointer.rs (2)

11-15: PyCPointerType wrapper layout looks consistent with the new subclass/payload approach.

---

58-68: The _base field design for pointer types is intentional and correct; no refactoring is needed.

The concern about pointer backing storage is based on a misunderstanding of the implementation. PyCPointer types intentionally store their value in a separate contents field (a PyRwLock) rather than in the _base.buffer. This design is consistent with how other complex ctypes like PyCArray also separate the inherited base class (_base: PyCData) from type-specific data storage. The empty buffer in _base is not a limitation—it's the correct representation for pointer types, which are value wrappers rather than memory buffers. All five pointer instantiation sites consistently use this pattern, there are no buffer size checks for pointers, and no downstream code attempts to access or depend on _base.buffer for pointer types.

crates/vm/src/vm/context.rs (1)

35-37: Bool caching via PyRef<PyBool> looks consistent and keeps new_bool() fast.

Also applies to: 306-307, 450-457

crates/vm/src/vm/vm_new.rs (1)

95-107: Good: new_exception() now asserts payload size matches PyBaseException.
This is helpful for catching layout regressions during the subclass-payload transition.

crates/vm/src/stdlib/ctypes/base.rs (3)

222-228: LGTM - New PyCData constructor.

The new constructor properly wraps the CDataObject in a PyRwLock, providing a clean API for creating PyCData instances.

---

238-241: LGTM - repr(transparent) for PyCSimpleType.

The #[repr(transparent)] attribute ensures PyCSimpleType has the same memory layout as its inner PyType, which is correct for the newtype wrapper pattern being adopted across this PR.

---

659-664: Data cloned into both _base and cdata.

The CDataObject is cloned and stored in both _base (via PyCData::new(cdata.clone())) and cdata (via PyRwLock::new(cdata)). This means modifications to one won't reflect in the other. If this is intentional (e.g., _base is only for type hierarchy and cdata is the working copy), please add a comment clarifying this design choice.

crates/derive-impl/src/pystructseq.rs (3)

448-452: LGTM - Newtype wrapper for PyStructSequence.

The generated struct correctly uses #[repr(transparent)] to wrap PyTuple, ensuring the memory layout matches the inner type. The public inner field (pub) allows direct access when needed.

---

481-496: LGTM - PyPayload implementation for struct sequences.

The implementation correctly:

• Delegates payload_type_id() to PyTuple to share the same type ID
• Uses fast_issubclass in validate_downcastable_from to properly handle subclass relationships
• Returns the static type from class()

This aligns with the external code snippets showing similar patterns.

---

498-513: LGTM - MaybeTraverse and PySubclass implementations.

The MaybeTraverse implementation correctly delegates to the inner PyTuple for GC traversal. The PySubclass implementation properly defines the base type relationship and provides access to the inner tuple via as_base().

crates/stdlib/src/socket.rs (5)

18-18: LGTM - PyOSError import added.

The import aligns with the updated error handling that now uses PyOSError subtypes.

---

1852-1852: LGTM - Timeout error now uses upcast.

The timeout_error(vm).upcast() correctly converts the PyRef<PyOSError> to PyBaseExceptionRef for the exception handling flow.

---

2420-2421: LGTM - Improved socket error construction.

Using new_os_subtype_error instead of new_exception preserves the specific error subtype (gaierror/herror), includes the error number, and maintains the error message. This provides better error information for debugging.

---

2424-2429: LGTM - Updated timeout error functions.

Both timeout_error and timeout_error_msg now return PyRef<PyOSError>, using new_os_subtype_error for consistent error construction with the timeout exception class. The None for errno is appropriate since timeouts don't have a specific system error number.

---

1829-1833: LGTM - From implementation for PyOSError.

This enables seamless conversion from PyRef<PyOSError> to IoOrPyException via upcast(), which safely converts the specialized exception type to its base PyBaseExceptionRef type through the generic method defined in crate::vm::object::core.

crates/vm/src/stdlib/ctypes/structure.rs (4)

17-20: LGTM - repr(transparent) for PyCStructType.

Consistent with the pattern applied to PyCSimpleType in base.rs, this ensures proper memory layout for the newtype wrapper.

---

222-229: Same duplication pattern as PyCSimple.

PyCStructure now has both _base: PyCData and cdata: PyRwLock<CDataObject>, following the same pattern as PyCSimple. The concern about potential inconsistencies between the two copies applies here as well.

---

299-304: Consistent construction pattern with PyCSimple.

The construction correctly creates a CDataObject and uses it for both _base and cdata. This is consistent with the approach in base.rs.

---

370-377: LGTM - Consistent construction in factory methods.

All factory methods (from_address, from_buffer, from_buffer_copy) follow the same pattern of creating a CDataObject and populating both _base and cdata fields consistently.

Also applies to: 423-430, 468-475

crates/vm/src/builtins/bool.rs (3)

4-4: LGTM - Import consolidation.

Minor formatting change to consolidate imports on one line.

---

88-97: LGTM - PyBool as repr(transparent) wrapper around PyInt.

The #[repr(transparent)] attribute ensures PyBool has the same layout as PyInt, enabling proper subclass payload handling. The Debug implementation correctly derives the boolean value from the inner bigint.

Note: The past review comment mentioned concerns about #[repr(C)] vs #[repr(transparent)] for base field layout. Using #[repr(transparent)] here is correct since it guarantees the same layout as the inner type.

---

21-34: Behavior change: TryFromBorrowedObject now accepts PyInt in addition to bool.

The implementation downcasts to PyInt instead of checking for the bool_type, accepting any integer where zero is falsy and non-zero is truthy. This aligns with Python semantics where bool is a subclass of int and bool(0) returns False while bool(n) returns True for any non-zero n.

Verify that this reflects the intended behavior: does the VM's type system follow Python's class hierarchy where bool is a subclass of int, or should bool conversion only accept actual bool instances? Check call sites and tests to confirm the expected usage.

crates/vm/src/stdlib/ctypes/union.rs (1)

15-44: Metaclass newtype looks fine; ensure fmt/clippy are clean.

The #[repr(transparent)] PyCUnionType(PyType) pattern is sensible for the new subclass payload layout; just make sure cargo fmt + cargo clippy are run since these metaclass wrappers can surface lint/trait/derive edge cases quickly.

crates/vm/src/stdlib/ctypes/array.rs (1)

25-28: PyCArrayType(PyType) wrapper is consistent with the PR direction.

crates/vm/src/stdlib/io.rs (5)

204-207: new_unsupported_operation() using new_os_subtype_error() is a nice consolidation; double-check the “errno None” semantics.
This matches the direction of the PR (centralized OS subtype construction). Just ensure callers don’t rely on UnsupportedOperation.errno being set in cases where CPython would leave it unset.

---

639-769: repr(transparent) base wrappers (_RawIOBase/_BufferedIOBase/_TextIOBase) look consistent; verify macro expectations around layout.
This is a core mechanism for the new payload layout. Please sanity-check that the #[pyclass(base = _IOBase)] machinery treats these as valid base payloads (esp. ZST base + transparent wrapper) across all supported compilers/targets.

---

1765-1950: Embedded _base fields: good direction; keep _base first everywhere to avoid layout surprises.
Most structs correctly place _base as the first field—please keep this invariant for any follow-ups (it matters a lot for transparent/base-embedded subclass payload schemes).

Also applies to: 2375-2382, 3656-3663, 3801-3810, 4440-4473

---

4245-4267: Singleton UnsupportedOperation type: avoid Context::genesis() if “multiple contexts” is a supported future.
If multiple Contexts are possible, consider keying the cache by Context (or storing on Context itself) rather than a process-global static created from genesis. If multiple contexts are impossible by design, a short comment here would prevent future refactors from breaking it.

---

82-97: The singleton Context assumption is architectural, not a bug. The code correctly uses Context::genesis() which is a true singleton via static initialization. All exception types and special objects in the codebase consistently rely on this same singleton Context design. This is an intentional architectural choice, not a hidden assumption. No changes are needed unless RustPython's design fundamentally shifts to support independent per-VM Contexts—which would require refactoring the entire context system, not just this function.

crates/vm/src/exceptions.rs (3)

966-969: Exception zoo extension for PyOSError is correctly simplified.
Dropping dynamic attribute wiring now that PyOSError has real fields is the right cleanup.

---

1235-1437: Broad #[repr(transparent)] wrapper rewrite looks consistent; please keep wrappers truly “transparent.”
Given how much relies on layout here, ensure none of these wrapper types ever gain extra fields (even accidentally) without also updating the subclass-payload assumptions. A brief doc comment near the pattern could help.

Also applies to: 1737-2204

---

1485-1522: No changes needed—current implementation is CPython-compatible.

The code correctly handles filename2 at index 4 when 5 arguments are provided. CPython uses the same argument structure across all platforms: OSError(errno, strerror, filename, winerror, filename2), where winerror at index 3 is simply unused/ignored on POSIX systems rather than being repurposed. There is no separate 4-argument form for POSIX systems.

Likely an incorrect or invalid review comment.