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

2313-2327: Guard the END_FOR skip with a POP_ITER check.

Skipping to target + 1 assumes a valid POP_ITER follows END_FOR. Consider guarding to avoid out-of-bounds or unexpected bytecode layouts.

💡 Suggested defensive guard

-                let jump_target = if let Some(unit) = self.code.instructions.get(target_idx) {
-                    if matches!(unit.op, bytecode::Instruction::EndFor) {
-                        // Skip END_FOR, jump to next instruction
-                        bytecode::Label(target.0 + 1)
-                    } else {
-                        // Legacy pattern: jump directly to target (POP_TOP/POP_ITER)
-                        target
-                    }
-                } else {
-                    target
-                };
+                let jump_target = if let Some(unit) = self.code.instructions.get(target_idx) {
+                    if matches!(unit.op, bytecode::Instruction::EndFor)
+                        && matches!(
+                            self.code.instructions.get(target_idx + 1).map(|u| &u.op),
+                            Some(bytecode::Instruction::PopIter)
+                        )
+                    {
+                        // Skip END_FOR, jump to POP_ITER
+                        bytecode::Label(target.0 + 1)
+                    } else {
+                        // Legacy pattern: jump directly to target (POP_TOP/POP_ITER)
+                        target
+                    }
+                } else {
+                    target
+                };

crates/compiler-core/src/bytecode/instruction.rs (1)

447-447: Simplified stack_effect signature removes jump parameter.

The stack_effect method now takes only arg: OpArg, removing the jump: bool parameter. This simplification is consistent across the codebase.

However, note that ForIter now returns a fixed +1 (line 509), which differs from CPython's behavior where jump=True (iterator exhausted) should return 0 and jump=False (value produced) should return +1. This was flagged in a previous review.

Since the ir.rs stack depth analysis no longer distinguishes jump paths, this may cause conservative stack depth estimates but shouldn't cause underflow. The comment on the previous review explains the semantic difference.

Also applies to: 509-509

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

2313-2332: Runtime instruction inspection may indicate a compiler-level opportunity.

The code inspects the instruction stream at runtime to detect the CPython 3.14 END_FOR/POP_ITER pattern and skip END_FOR on loop exhaustion. While this works correctly, runtime instruction inspection is unusual and could be fragile if bytecode patterns change.

Consider whether the compiler could emit a different jump target directly, or if FOR_ITER should have an additional operand to indicate the number of instructions to skip. This would eliminate the runtime pattern matching.

crates/compiler-core/src/bytecode/instruction.rs (1)

447-728: Re-check FOR_ITER jump-path stack effect with the new API.

stack_effect now ignores jump direction and ForIter returns +1. If jump-path depth still differs (iterator exhausted), stack depth analysis can drift. Consider a jump-aware path or special-casing ForIter in depth analysis if needed.

crates/codegen/src/ir.rs (1)

339-346: Add a debug assertion that JumpNoInterrupt is backward-only.

This arm always emits JumpBackwardNoInterrupt; an assertion would catch unexpected forward targets early.

♻️ Suggested debug-assert

                         AnyInstruction::Pseudo(PseudoInstruction::JumpNoInterrupt { .. })
                             if target != BlockIdx::NULL =>
                         {
-                            // JumpNoInterrupt is always backward (used in yield-from/await loops)
+                            let target_offset = block_to_offset[target.idx()].0;
+                            debug_assert!(
+                                target_offset <= current_offset,
+                                "JumpNoInterrupt must be backward"
+                            );
+                            // JumpNoInterrupt is always backward (used in yield-from/await loops)
                             Instruction::JumpBackwardNoInterrupt {
                                 target: Arg::marker(),
                             }
                         }