Ensure `BuildSlice` oparg to be either 2 or 3 by ShaharNaveh · Pull Request #6313 · RustPython/RustPython

coderabbitai

1153-1167: BuildSliceArgCount enum correctly constrains allowed BUILD_SLICE arg counts

Defining BuildSliceArgCount with repr(u8) and values { Two = 2, Three = 3 } via op_arg_enum! ensures that only opargs 2 or 3 round-trip through OpArgType and Arg<T>. This is a clean way to encode the CPython-style 2/3 argument semantics for BUILD_SLICE and directly supports the PR’s goal of rejecting other arg counts.

762-764: Instruction::BuildSlice wiring (encoding, stack effect, display) is consistent; consider compatibility expectations

Switching BuildSlice to argc: Arg<BuildSliceArgCount> and computing the stack effect as 1 - argc keeps the net stack change correct for both 2- and 3-argument cases, and the disassembly now prints the enum (Two/Three), which remains informative.

One behavioral change is that invalid encoded arg values (e.g., legacy 0/1 encodings or corrupt bytecode) will now cause Arg::get → BuildSliceArgCount::from_op_arg to return None and panic on unwrap, whereas previously any non-zero oparg was treated as “has step”. This matches how other op_arg_enum!-based instructions already behave, but it does tighten the contract for BUILD_SLICE.

If you rely on loading older or third-party bytecode streams, it’s worth double-checking that they already encode BUILD_SLICE with argument counts 2 or 3, or that such bytecode is rejected before execution.

Also applies to: 1565-1569, 1756-1756