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

528-538: Extract a shared vectorcall-to-slot_new helper to avoid drift.

Line 528-Line 538 duplicates the same trampoline used by multiple builtins. Centralizing this in one helper would keep behavior consistent and lower maintenance risk.

Proposed refactor sketch

+// e.g. in a shared builtins/type helper module
+pub(crate) fn vectorcall_via_slot_new(
+    zelf_obj: &PyObject,
+    args: Vec<PyObjectRef>,
+    nargs: usize,
+    kwnames: Option<&[PyObjectRef]>,
+    vm: &VirtualMachine,
+) -> PyResult {
+    let zelf: &Py<PyType> = zelf_obj.downcast_ref().unwrap();
+    let func_args = FuncArgs::from_vectorcall_owned(args, nargs, kwnames);
+    (zelf.slots.new.load().unwrap())(zelf.to_owned(), func_args, vm)
+}

Then each builtin can just store that helper in its slots.vectorcall.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/vm/src/builtins/float.rs` around lines 528 - 538, The vectorcall_float
trampoline duplicates the pattern of converting vectorcall args to FuncArgs and
invoking the type's slot_new (see vectorcall_float,
FuncArgs::from_vectorcall_owned, and
(zelf.slots.new.load().unwrap())(zelf.to_owned(), func_args, vm)); extract that
logic into a single reusable helper (e.g., a function that accepts zelf_obj,
args, nargs, kwnames, vm and performs the downcast, FuncArgs conversion, and
calls slot_new) and have builtins set their slots.vectorcall to point to this
helper to avoid drift and ensure consistent behavior across types.

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

698-709: ⚠️ Potential issue | 🟠 Major

vectorcall_tuple skips subtype slot_init after slot_new.

This path returns right after slot_new, so subtype init hooks are bypassed. It should mirror PyType::call’s new→init sequence when applicable.

💡 Suggested fix

 fn vectorcall_tuple(
     zelf_obj: &PyObject,
     args: Vec<PyObjectRef>,
     nargs: usize,
     kwnames: Option<&[PyObjectRef]>,
     vm: &VirtualMachine,
 ) -> PyResult {
     let zelf: &Py<PyType> = zelf_obj.downcast_ref().unwrap();
     let func_args = FuncArgs::from_vectorcall_owned(args, nargs, kwnames);
-    // Use the type's own slot_new rather than calling PyTuple::slot_new directly,
-    // so Rust-level subclasses (e.g. struct sequences) get their custom slot_new called.
-    (zelf.slots.new.load().unwrap())(zelf.to_owned(), func_args, vm)
+    let obj = (zelf.slots.new.load().unwrap())(zelf.to_owned(), func_args.clone(), vm)?;
+    if obj.class().fast_issubclass(zelf) {
+        if let Some(init_method) = obj.class().slots.init.load() {
+            init_method(obj.clone(), func_args, vm)?;
+        }
+    }
+    Ok(obj)
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/vm/src/builtins/tuple.rs` around lines 698 - 709, vectorcall_tuple
currently calls the type's slot_new and returns immediately, skipping any
subclass slot_init; update vectorcall_tuple to mirror PyType::call's new→init
sequence: after invoking (zelf.slots.new.load().unwrap()) and obtaining the
created object, check whether the type has a non-default slot_init (e.g., via
zelf.slots.init.load() or the same mechanism used in PyType::call), and if so
call that init slot with the same FuncArgs and vm; propagate any error from
slot_init and return the created instance on success, ensuring
ownership/borrowing follows the existing pattern (use zelf.to_owned() and the
created PyObjectRef as in the surrounding code).

crates/vm/src/stdlib/os.rs (1)

1371-1379: ⚠️ Potential issue | 🟠 Major

st_*_ns fallback handling is missing.

Line 1374 leaves nanosecond fields unset when omitted. That can break st_atime_ns/st_mtime_ns/st_ctime_ns consistency for sequence-based construction.

💡 Suggested fix

             for i in 7..=9 {
                 if vm.is_none(&items[i + 3]) {
                     items[i + 3] = items[i].clone();
                 }
+                if vm.is_none(&items[i + 6]) {
+                    let billion: PyObjectRef = vm.ctx.new_int(1_000_000_000).into();
+                    items[i + 6] = vm._mul(&items[i], &billion)?;
+                }
             }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/vm/src/stdlib/os.rs` around lines 1371 - 1379, The loop that copies
integer time fields to float timestamp slots (for i in 7..=9) neglects to set
the corresponding nanosecond slots (items[i+6]) when they are omitted; update
the loop in the same block to check vm.is_none(&items[i + 6]) and, if missing,
set items[i + 6] to a zero-nanoseconds value (e.g., an integer zero) so
st_atime_ns/st_mtime_ns/st_ctime_ns are populated consistently alongside the
float timestamps and integer seconds.

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

771-782: ⚠️ Potential issue | 🟠 Major

This fast path also skips subtype slot_new.

PyList::default().into_ref_with_type(...) has the same hazard as dict: a Rust-defined list subtype can inherit this vectorcall and be allocated as a plain PyList instead of going through its own constructor path. Please guard this fast path on the builtin list slots or fall back to the generic type call path.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/vm/src/builtins/list.rs` around lines 771 - 782, The fast path in
vectorcall_list incorrectly constructs a PyList for arbitrary subtypes via
PyList::default().into_ref_with_type(...), skipping subtype construction; change
vectorcall_list to only take the fast path when the target type is the exact
builtin list type or when its new/slot_new is the builtin implementation (i.e.,
check the type against vm.ctx.types.list_type or compare its slot_new to the
builtin slot), and otherwise fall back to the generic type call path so subclass
constructors (slot_new) run; keep references to vectorcall_list,
PyList::default().into_ref_with_type, PyList::slot_init and slot_new to locate
and update the logic.

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

1438-1449: ⚠️ Potential issue | 🟠 Major

This still bypasses subtype slot_new.

PyDict::default().into_ref_with_type(...) never consults the target type’s own constructor slots, so a Rust-defined dict subtype can inherit this vectorcall and skip its allocator/init hooks here. Please fall back to the generic type call path unless the target is still using dict’s builtin new/init slots.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/vm/src/builtins/dict.rs` around lines 1438 - 1449, vectorcall_dict
currently creates an instance with PyDict::default().into_ref_with_type(...)
which bypasses the target type’s own constructor slots; change it to first
detect whether the target type still uses dict’s builtin new/init slots (i.e.,
compare the target type’s slot_new/slot_init to PyDict’s defaults or check type
identity), and only use PyDict::default().into_ref_with_type + PyDict::slot_init
when they match; otherwise fall back to the generic type call path (invoke the
type’s normal call/constructor path via the VM so overridden alloc/init run)
instead of instantiating directly.

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

462-468: ⚠️ Potential issue | 🟠 Major

Constructor vectorcall inheritance is blocked for non-callable builtins.

Line 462 and Line 590 gate slots.vectorcall inheritance on slots.call. That prevents subclasses of constructor-only builtins (dict, list, int, etc.) from inheriting constructor vectorcall and forces fallback to generic construction (crates/vm/src/builtins/type.rs, Line 2686).

Suggested fix

             Self::TpCall => {
                 inherit_main!(call);
-                let inherited_vc = mro.iter().find_map(|cls| {
-                    if cls.slots.call.load().is_some() {
-                        cls.slots.vectorcall.load()
-                    } else {
-                        None
-                    }
-                });
+                let inherited_vc = mro.iter().find_map(|cls| cls.slots.vectorcall.load());
                 typ.slots.vectorcall.store(inherited_vc);
             }

             Self::TpCall => {
                 copy_main!(call);
-                if typ.slots.vectorcall.load().is_none()
-                    && base.slots.call.load().is_some()
-                    && let Some(base_val) = base.slots.vectorcall.load()
+                if typ.slots.vectorcall.load().is_none()
+                    && let Some(base_val) = base.slots.vectorcall.load()
                 {
                     typ.slots.vectorcall.store(Some(base_val));
                 }
             }

Also applies to: 590-594

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/vm/src/types/slot_defs.rs` around lines 462 - 468, The code currently
prevents inheriting slots.vectorcall when slots.call is absent (see the
inherited_vc computation using mro.iter().find_map), which blocks
constructor-only builtins from inheriting vectorcall; change the predicate to
check only for the presence of cls.slots.vectorcall (not cls.slots.call) so
vectorcall is inherited independently of call. Apply the same fix to the other
similar block that conditions vectorcall on call (the second mro.iter().find_map
instance around slots.vectorcall) so subclasses of constructor-only builtins can
inherit constructor vectorcall.