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

8416-8431: Extract the StopIteration wrapper into a shared helper.

This setup/teardown sequence is now effectively duplicated from Compiler::compile_function_body at Lines 3877-3892 and Lines 3924-3939. Any later tweak to handler depth, location suppression, or block layout now has to stay in sync in two places.

♻️ Suggested shape

-        let stop_iteration_block = if is_gen_scope {
-            let handler_block = self.new_block();
-            emit!(
-                self,
-                PseudoInstruction::SetupCleanup {
-                    delta: handler_block
-                }
-            );
-            self.set_no_location();
-            self.push_fblock(FBlockType::StopIteration, handler_block, handler_block)?;
-            Some(handler_block)
-        } else {
-            None
-        };
+        let stop_iteration_block = self.enter_stop_iteration_wrapper(is_gen_scope)?;
...
-        if let Some(handler_block) = stop_iteration_block {
-            emit!(self, PseudoInstruction::PopBlock);
-            self.set_no_location();
-            self.pop_fblock(FBlockType::StopIteration);
-            self.switch_to_block(handler_block);
-            emit!(
-                self,
-                Instruction::CallIntrinsic1 {
-                    func: oparg::IntrinsicFunction1::StopIterationError
-                }
-            );
-            self.set_no_location();
-            emit!(self, Instruction::Reraise { depth: 1u32 });
-            self.set_no_location();
-        }
+        self.exit_stop_iteration_wrapper(stop_iteration_block);

Also applies to: 8522-8538

🤖 Prompt for AI Agents

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

In `@crates/codegen/src/compile.rs` around lines 8416 - 8431, Extract the
duplicated StopIteration setup/teardown into a shared helper (e.g., a method on
the compiler like setup_stop_iteration_handler or wrap_with_stopiteration) that
encapsulates the logic currently using is_gen_scope, self.new_block(), emitting
PseudoInstruction::SetupCleanup { delta: handler_block },
self.set_no_location(), and self.push_fblock(FBlockType::StopIteration,
handler_block, handler_block) and returns Option<handler_block>; then replace
the duplicated blocks that create stop_iteration_block (the sequences in
compile_function_body and the other location around is_gen_scope/is_async) with
a call to that helper so both sites share the same behavior and return value.

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

228-229: Consider adding a TODO comment explaining why duplicate_exits_without_lineno is disabled.

The comment "pending stackdepth fix" is helpful, but linking to a tracking issue would make it easier to follow up.

🤖 Prompt for AI Agents

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

In `@crates/codegen/src/ir.rs` around lines 228 - 229, Update the existing TODO
comment above the disabled call to duplicate_exits_without_lineno(&mut
self.blocks) to include a reference to the tracking issue or bug ID and a short
timestamp/owner tag (e.g., "pending stackdepth fix - see ISSUE-1234
`@2026-03-30`") so future readers can find the follow-up; leave the call commented
out but expand the comment to mention the exact reason ("stackdepth calculation
bug") and the issue link/number and optionally who filed it.

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

319-326: The unimplemented! panic is appropriately documented.

The comment clearly explains that PyObjBag lacks VirtualMachine access needed for frozenset hashing, and that PyMarshalBag handles this case. Consider adding a link to where PyMarshalBag implements this, or logging a warning if this path is ever hit unexpectedly.

🤖 Prompt for AI Agents

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

In `@crates/vm/src/builtins/code.rs` around lines 319 - 326, In the
BorrowedConstant::Frozenset arm inside PyObjBag::make_constant, replace the bare
unimplemented!() with a logged warning that clearly states this path should be
handled by PyMarshalBag (reference PyMarshalBag's frozenset handling in the
message) and include a link or code reference to where PyMarshalBag implements
it; after logging, either return an appropriate Err or keep the unimplemented
panic if you want to preserve current behavior, but ensure the warning is
emitted first so unexpected hits are observable.

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

934-935: Note: Frozenset hash implementation doesn't account for set semantics.

The current hash implementation hashes elements in order, but frozensets are unordered. If two Frozenset constants have the same elements in different orders, they would have different hashes but should compare equal. However, since this is used for constant pool deduplication and constants are typically created in a deterministic order, this may be acceptable.

🤖 Prompt for AI Agents

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

In `@crates/compiler-core/src/bytecode.rs` around lines 934 - 935, The Frozenset
arm currently calls elements.hash(state) which is order-dependent; change it to
an order-independent hashing strategy so frozensets with the same elements in
different orders produce identical hashes. In the Frozenset match arm (the
Frozenset { elements } branch inside the Hash impl for constants), compute each
element's hash into a temporary value, sort those element-hash values (or
otherwise combine them with a commutative operation like XOR/add on u64 hashes),
then feed the sorted/combined result into the provided state so hashing is
deterministic and order-independent.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes