GeezerVison

# Check current state of instruction.rs implementation
fd -t f instruction.rs | head -5

# Check the full context around line 1716-1724
head -1750 crates/compiler-core/src/bytecode/instruction.rs | tail -60

# Search for all stack_effect_jump implementations in the codebase
rg "stack_effect_jump" -B 2 -A 5

# Check what branch-sensitive opcodes exist in Instruction enum
rg "enum Instruction" -A 200 crates/compiler-core/src/bytecode/instruction.rs | head -250

# Search for ForIter stack_effect implementation
rg "ForIter" -B 3 -A 8 crates/compiler-core/src/bytecode/instruction.rs | grep -A 20 "stack_effect"

# Look for all branch target instructions (those with Label arguments)
rg "Arg<Label>" crates/compiler-core/src/bytecode/instruction.rs

# Check the CPython bytecode documentation for FOR_ITER
web_search
FOR_ITER CPython 3.14 stack effect branch exhausted

# Search for stack_effect_info implementations to understand current semantics
rg "fn stack_effect_info" -B 2 -A 15 crates/compiler-core/src/bytecode/instruction.rs | head -100

# Search specifically for ForIter stack effect
rg "ForIter" -A 2 crates/compiler-core/src/bytecode/instruction.rs | grep -A 50 "match self"

# Get a larger context of the stack_effect_info match statement to find ForIter
sed -n '/fn stack_effect_info/,/^    }/p' crates/compiler-core/src/bytecode/instruction.rs | grep -A 2 "ForIter"

# Check complete Instruction stack_effect_info implementation
sed -n '1200,1650p' crates/compiler-core/src/bytecode/instruction.rs | grep -B 5 -A 5 "ForIter"

# Search for all match arms in stack_effect_info for instructions with Label/conditional behavior
sed -n '/fn stack_effect_info/,/^    }/p' crates/compiler-core/src/bytecode/instruction.rs | grep -E "(Instrumented|Jump|Iter|Await|Except)" | head -30

# Check the test file to see if there are any test cases for stack_effect_jump with FOR_ITER
find . -name "*.py" -o -name "*.rs" | xargs grep -l "test_stack_effect_jump" 2>/dev/null

# Look for InstrumentedForIter definition and understand it
rg "InstrumentedForIter" -B 2 -A 5 crates/compiler-core/src/bytecode/instruction.rs

# Check if there are any other instructions documented as having different branch/fallthrough effects
rg "jump=True" -B 3 -A 3 crates/compiler-core/src/bytecode/instruction.rs

# Check how Instruction is used in the match statement - does it include InstrumentedForIter?
rg "InstrumentedForIter" crates/compiler-core/src/bytecode/instruction.rs | head -20

# Look at the Instruction enum definition to understand the hierarchy
sed -n '/pub enum Instruction/,/^}/p' crates/compiler-core/src/bytecode/instruction.rs | grep -E "(InstrumentedForIter|ForIter)" -B 1 -A 1

# Check if there's a deoptimize() method mentioned in the proposed fix
rg "fn deoptimize" -B 2 -A 10 crates/compiler-core/src/bytecode/instruction.rs

# Verify the actual test expectations in test__opcode.py
cat Lib/test/test__opcode.py | grep -A 20 "def test_stack_effect_jump"

# Let me check the CPython version more carefully
grep -r "3.14\|3.13" crates/compiler-core/src/bytecode/instruction.rs | head -5

# Check the full test_stack_effect_jump function to understand better
sed -n '/def test_stack_effect_jump/,/def test_/p' Lib/test/test__opcode.py | head -60

# Check CPython reference - let's look for any documentation in the codebase
rg "stack_effect.*jump.*FOR_ITER\|FOR_ITER.*jump.*-1" -i

# Get more context on the semantics - check what branch (jump=True) actually means in CPython
python3 << 'EOF'
import dis

# Check FOR_ITER semantics
FOR_ITER = dis.opmap.get('FOR_ITER')
if FOR_ITER:
    print(f"FOR_ITER opcode: {FOR_ITER}")
    print(f"stack_effect(FOR_ITER, 0): {dis.stack_effect(FOR_ITER, 0)}")
    print(f"stack_effect(FOR_ITER, 0, jump=True): {dis.stack_effect(FOR_ITER, 0, jump=True)}")
    print(f"stack_effect(FOR_ITER, 0, jump=False): {dis.stack_effect(FOR_ITER, 0, jump=False)}")
else:
    print("FOR_ITER not found")
EOF

# Check if RustPython's test expectations are correct - this is critical
cat Lib/test/test__opcode.py | grep -B 5 -A 8 "def test_stack_effect_jump"

# Now check what other opcodes might have branch-sensitive semantics in CPython 3.14
python3 << 'EOF'
import dis
import opcode

# Get all opcodes
for name in sorted(dis.opmap.keys()):
    code = dis.opmap[name]
    # Skip instrumented opcodes
    if code >= opcode.MIN_INSTRUMENTED_OPCODE:
        continue
    
    try:
        if code not in dis.hasarg:
            jump_true = dis.stack_effect(code, jump=True)
            jump_false = dis.stack_effect(code, jump=False)
        else:
            jump_true = dis.stack_effect(code, 0, jump=True)
            jump_false = dis.stack_effect(code, 0, jump=False)
        
        # Check if this is a branch-sensitive opcode (jump effects differ)
        if jump_true != jump_false:
            print(f"{name:30} jump=True: {jump_true:3}, jump=False: {jump_false:3}")
    except:
        pass
EOF

# Check the current state of the Instruction match in stack_effect_jump - does it have any overrides?
sed -n '/impl InstructionMetadata for Instruction/,/^}/p' crates/compiler-core/src/bytecode/instruction.rs | grep -A 10 "fn stack_effect_jump"

# Let me try a simpler approach to find all branch-sensitive opcodes
python3 << 'EOF'
import dis

# Get all opcodes and check which ones have different jump effects
branch_sensitive = []
for name in sorted(dis.opmap.keys()):
    code = dis.opmap[name]
    
    try:
        if code not in dis.hasarg:
            jump_true = dis.stack_effect(code, jump=True)
            jump_false = dis.stack_effect(code, jump=False)
        else:
            jump_true = dis.stack_effect(code, 0, jump=True)
            jump_false = dis.stack_effect(code, 0, jump=False)
        
        # Check if this is a branch-sensitive opcode (jump effects differ)
        if jump_true != jump_false:
            branch_sensitive.append((name, jump_true, jump_false))
    except:
        pass

print("Branch-sensitive opcodes (jump=True vs jump=False differ):")
for name, jump_true, jump_false in branch_sensitive:
    print(f"  {name:30} jump=True: {jump_true:3}, jump=False: {jump_false:3}")
EOF

# Now let's verify the current state - does Instruction override stack_effect_jump?
rg "impl InstructionMetadata for Instruction" -A 50 crates/compiler-core/src/bytecode/instruction.rs | head -60

# Double-check what the review test expectations actually are in RustPython
grep -A 5 "FOR_ITER.*jump=True" Lib/test/test__opcode.py

# This is critical - let me verify the exact CPython version RustPython is targeting
grep -i "cpython.*3\." crates/compiler-core/src/bytecode/instruction.rs | head -3

# Check what version of Python is being used in the test environment
python3 --version

# The critical finding: verify CPython 3.14 FOR_ITER semantics one more time with explicit checks
python3 << 'EOF'
import sys
import dis

print(f"Python version: {sys.version}")
print()

# Check FOR_ITER explicitly
FOR_ITER = dis.opmap.get('FOR_ITER')
if FOR_ITER is not None:
    print(f"FOR_ITER opcode number: {FOR_ITER}")
    try:
        effect_default = dis.stack_effect(FOR_ITER, 0)
        effect_jump_true = dis.stack_effect(FOR_ITER, 0, jump=True)
        effect_jump_false = dis.stack_effect(FOR_ITER, 0, jump=False)
        print(f"  stack_effect(FOR_ITER, 0): {effect_default}")
        print(f"  stack_effect(FOR_ITER, 0, jump=True): {effect_jump_true}")
        print(f"  stack_effect(FOR_ITER, 0, jump=False): {effect_jump_false}")
        print()
        if effect_jump_true != effect_jump_false:
            print(f"  ✓ FOR_ITER is BRANCH-SENSITIVE (jump effects differ)")
        else:
            print(f"  ✗ FOR_ITER is NOT branch-sensitive (jump effects are same)")
    except Exception as e:
        print(f"  Error: {e}")
EOF

# Check if there's a comment or documentation in RustPython test about what the semantics SHOULD be
grep -B 10 -A 10 "test_stack_effect_jump" Lib/test/test__opcode.py | head -30

# This is a critical discovery - let me check if the test in RustPython is known to be wrong
git log --oneline -20 Lib/test/test__opcode.py 2>/dev/null | head -10

# Check the git history of the test to see if it was recently changed
git log -p --follow -S "stack_effect_jump" -- Lib/test/test__opcode.py 2>/dev/null | head -100

# Check when this test was added and what it's supposed to test
git log --all --oneline -- Lib/test/test__opcode.py 2>/dev/null | head -5

# Check the issue - is FOR_ITER truly branch-sensitive in CPython 3.14?
# Let me check the actual CPython bytecodes.c for v3.14.2
web_search
CPython v3.14.2 FOR_ITER bytecode stack effect jump exhausted

# Let me examine the commit that added stack_effect_jump to understand the intent
git show 89191b8f --stat 2>/dev/null | head -40

# Check if there are any issues or PRs related to this
git log --all --grep="stack_effect_jump\|FOR_ITER" --oneline 2>/dev/null | head -20

# Most importantly - let's verify the semantics by looking at the actual implementation expectations
# Check what max_stackdepth expects from stack_effect_jump
rg "max_stackdepth\|stack_effect_jump" -B 3 -A 3 crates/codegen/src/ir.rs | head -80

# Verify the retrieved learning is still relevant and accurate
rg "is_conditional_jump\|ForIter\|NOT_TAKEN" -B 2 -A 5 crates/codegen/src/ir.rs | head -50

# Now let's see if the actual implementation was done in that commit
git show 89191b8f -- crates/compiler-core/src/bytecode/instruction.rs 2>/dev/null | grep -A 30 "stack_effect_jump"

# Check what the commit actually changed for Instruction::stack_effect_jump
git show 89191b8f -- crates/compiler-core/src/bytecode/instruction.rs 2>/dev/null | grep -B 5 -A 20 "impl InstructionMetadata for Instruction"

# Most importantly - verify if the test was also updated in that commit
git show 89191b8f -- Lib/test/test__opcode.py 2>/dev/null | head -100

# This is very revealing - the commit message says ForIter branch=-1, but the impl doesn't override
# Let's check if there's a follow-up commit that implements the overrides
git log --oneline --all 89191b8f..HEAD -- crates/compiler-core/src/bytecode/instruction.rs 2>/dev/null | head -10

# Check if Instruction has any stack_effect_jump override currently
git show HEAD:crates/compiler-core/src/bytecode/instruction.rs 2>/dev/null | grep -A 30 "impl InstructionMetadata for Instruction" | grep -A 10 "stack_effect_jump"

# Check what the test file expects right now
git show HEAD:Lib/test/test__opcode.py 2>/dev/null | grep -A 5 "def test_stack_effect_jump"

# Verify if Send also needs an override
python3 << 'EOF'
import dis

SEND = dis.opmap.get('SEND')
if SEND:
    print(f"SEND opcode: {SEND}")
    print(f"  stack_effect(SEND, 0): {dis.stack_effect(SEND, 0)}")
    print(f"  stack_effect(SEND, 0, jump=True): {dis.stack_effect(SEND, 0, jump=True)}")
    print(f"  stack_effect(SEND, 0, jump=False): {dis.stack_effect(SEND, 0, jump=False)}")
else:
    print("SEND not found")
EOF

# Verify the final state - check if there are any recent commits fixing this
git log --oneline -5 2>/dev/null

# Final check: verify the Send instruction exists in Instruction enum
rg "Send\s*\{" crates/compiler-core/src/bytecode/instruction.rs | head -3

 impl InstructionMetadata for Instruction {
+    fn stack_effect_jump(&self, oparg: u32) -> i32 {
+        match self {
+            Self::ForIter { .. } | Self::Send { .. } => -1,
+            _ => self.stack_effect(oparg),
+        }
+    }
+
     #[inline]
     fn label_arg(&self) -> Option<Arg<Label>> {

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

In `@crates/compiler-core/src/bytecode/instruction.rs` around lines 1716 - 1724,
Implement branch-sensitive stack effects by overriding stack_effect_jump for the
opcodes ForIter and Send: in the Instruction trait's stack_effect_jump
implementation, match on self (or the instruction variant) and return -1 for
ForIter and -1 for Send (regardless of oparg), otherwise fall back to calling
self.stack_effect(oparg); this ensures branch edges use the correct values used
by max_stackdepth and the exposed stack_effect(jump=True). Also update the unit
test expectation in test__opcode.py to assert stack_effect(FOR_ITER, 0,
jump=True) == -1 instead of 1.

#!/bin/bash
set -euo pipefail

echo "Local RustPython implementation (changed block):"
sed -n '189,200p' crates/stdlib/src/_opcode.rs

echo
echo "CPython reference check (v3.14.2):"
curl -sL https://raw.githubusercontent.com/python/cpython/v3.14.2/Modules/_opcode.c \
  | rg -n "jump == Py_None|jump == Py_True|jump == Py_False|jump must be False, True or None" -C2

-        let jump: Option<bool> = match args.jump {
-            Some(v) => {
-                if vm.is_none(&v) {
-                    None
-                } else {
-                    Some(v.try_to_bool(vm).map_err(|_| {
-                        vm.new_value_error("stack_effect: jump must be False, True or None")
-                    })?)
-                }
-            }
-            None => None,
-        };
+        let jump: Option<bool> = match args.jump {
+            Some(v) if vm.is_none(&v) => None,
+            Some(v) if v.fast_isinstance(vm.ctx.types.bool_type) => Some(v.try_to_bool(vm)?),
+            Some(_) => {
+                return Err(vm.new_value_error(
+                    "stack_effect: jump must be False, True or None",
+                ));
+            }
+            None => None,
+        };

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

In `@crates/stdlib/src/_opcode.rs` around lines 189 - 200, The current parsing of
args.jump uses try_to_bool which accepts truthy/falsy objects; instead, in the
stack_effect implementation ensure args.jump only accepts identity True, False
or None: when handling args.jump (the variable jump / match arm using vm.is_none
and v), check explicitly for None, then check identity for True and False (use
the VM/context identity checks available) and return Some(true) or Some(false)
accordingly; for any other object return vm.new_value_error("stack_effect: jump
must be False, True or None") so non-boolean truthy/falsy values raise
ValueError.