As discussed in my PR, this will not work.

Removed, replaced with f67a934#diff-6cb426843cb08f1943a128f6df3e3e46e3862a5eae416e33d45a079529eab6b2

Duplicate exported symbol PyObject_CallMethodObjArgs — link error / ABI corruption.

This Rust definition collides with the variadic C definition in crates/capi/csrc/pyobject_callmethodobjargs.c#L13-L20. Both have external linkage with the same name (Rust uses #[unsafe(no_mangle)], C is non-static), both end up in the same rustpython-capi rlib (the C file is compiled by cc::Build in crates/capi/build.rs), and lib.rs even adds #[used] static KEEP_PYOBJECT_CALL_METHOD_OBJ_ARGS to force this Rust version to be retained.

Most linkers (gnu-ld with --whole-archive, lld in cdylib mode, etc.) will fail with a multiple-definition error. On macOS the linker can silently pick one — and the two signatures are not interchangeable: the C entry is variadic with a NULL sentinel, this Rust entry takes 8 fixed *mut PyObject slots. If the Rust version wins, real CPython callers that pass more than 8 args (or that pass the NULL terminator) get garbage in the trailing slots; if the C version wins, this Rust function is dead code.

Since the C wrapper already implements the variadic ABI and just dispatches to RustPython_PyObject_CallMethodObjArgsArray, the simplest fix is to delete this Rust function (and the matching #[used] static in lib.rs).

Vectorcall drops keyword-argument values — wrong result / runtime panic when any kwargs are passed.

This slice reads only args_len (positional count) entries from the C-supplied args buffer. CPython's vectorcall ABI requires that when kwnames is non-NULL the buffer holds nargs + len(kwnames) entries — positional values at args[0..nargs] and keyword values at args[nargs..nargs+nkwargs]. See Python docs / vectorcall:

If kwnames is not NULL, it must be a tuple of strings naming the keyword arguments. The values of these arguments are stored in args after the positional arguments.

Downstream, FuncArgs::from_vectorcall_owned does args.drain(nargs..nargs + kw_count) (see crates/vm/src/function/argument.rs#L177-L186), which will index past the end of this truncated Vec whenever kwnames is non-empty (debug-asserts in debug, OOB drain panic in release). Any vectorcall through this facade with keyword arguments is broken.

PyObject_VectorcallMethod at L167-L172 builds its own slice the same way, but since it then re-enters this function through args.as_ptr() (still pointing into the original C buffer where the kwarg values live), fixing only PyObject_Vectorcall is enough: resolve kwnames length first and slice args_len + kwnames_len from the raw pointer.