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

1293-1302: Consider avoiding String allocations by using reference-based comparison.

Building a HashSet<String> with to_string() on every call creates heap allocations. Since PyStrInterned references are interned and can be compared directly, you can avoid these allocations:

♻️ Suggested optimization using pointer comparison

-        let varnames_set: std::collections::HashSet<String> =
-            self.code.varnames.iter().map(|s| s.to_string()).collect();
-        let nonparam_cellvars: Vec<_> = self
-            .code
-            .cellvars
-            .iter()
-            .filter(|s| !varnames_set.contains(&s.to_string()))
-            .collect();
+        let nonparam_cellvars: Vec<_> = self
+            .code
+            .cellvars
+            .iter()
+            .filter(|cv| !self.code.varnames.iter().any(|v| *v == **cv))
+            .collect();

Alternatively, if the cellvars/varnames lists are large enough that O(n²) becomes a concern, consider caching the nonparam_cellvars computation in the PyCode struct.

🤖 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 1293 - 1302, The current code
builds a HashSet<String> by calling to_string() on each element of
self.code.varnames which causes unnecessary heap allocations; change the
comparison to use references/borrowed interned strings instead (e.g., compare
PyStrInterned or &str values directly) so you avoid allocating in varnames_set
and when filtering self.code.cellvars for nonparam_cellvars, or alternatively
compute and cache nonparam_cellvars inside PyCode to avoid repeated O(n²) work;
update usages of varnames_set, nonparam_cellvars, self.code.varnames, and
self.code.cellvars accordingly to use reference-based comparisons rather than
String allocations.

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

2029-2038: Fix doc-comment association after inserting the new helper.

duplicate_end_returns docs are now attached to add_generator_stop_handler, which makes rustdoc misleading. Move the return-duplication docs back above fn duplicate_end_returns(...) and keep only StopIteration-handler docs above this helper.

Suggested doc-comment move

-/// Duplicate `LOAD_CONST None + RETURN_VALUE` for blocks that fall through
-/// to the final return block. Matches CPython's behavior of ensuring every
-/// code path that reaches the end of a function/module has its own explicit
-/// return instruction.
 /// Add a StopIteration → RuntimeError handler for generators/coroutines.
 /// CPython: flowgraph.c add_stopiteration_handler()
 /// Appends a handler block that wraps the entire generator body.
 fn add_generator_stop_handler(_flags: CodeFlags, _blocks: &mut Vec<Block>) {
@@
 }
 
+/// Duplicate `LOAD_CONST None + RETURN_VALUE` for blocks that fall through
+/// to the final return block. Matches CPython's behavior of ensuring every
+/// code path that reaches the end of a function/module has its own explicit
+/// return instruction.
 fn duplicate_end_returns(blocks: &mut [Block]) {

As per coding guidelines, "Do not delete or rewrite existing comments unless they are factually wrong or directly contradict the new code."

🤖 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 2029 - 2038, The doc comment block
describing return-duplication was accidentally left above the new helper; move
the duplicate_end_returns doc comment back directly above the fn
duplicate_end_returns(...) declaration and leave only the StopIteration/handler
documentation immediately above fn add_generator_stop_handler(...), ensuring
each function has its correct doc-comment so rustdoc associates them with the
intended symbols.

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

7919-7934: Please lock the new call lowering with a disassembly regression.

Both the explicit tuple materialization for CallFunctionEx and the comprehension CALL { argc: 0 } path are stack-shape-sensitive. A focused snapshot for a starred/**kwargs call and a comprehension invocation would make parity regressions much easier to catch.

As per coding guidelines, "When modifying bytecode instructions, perform a clean build by running: rm -r target/debug/build/rustpython-* && find . | grep -E "\.pyc$" | xargs rm -r".

Also applies to: 8292-8293

🤖 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 7919 - 7934, Add a disassembly
regression test that locks the new call lowering behavior for both the
starred/**kwargs path (CallFunctionEx lowering) and the comprehension invocation
path that emits CALL { argc: 0 }; specifically create focused snapshot tests
that exercise a starred/`**kwargs` call and a comprehension call so any
stack-shape-sensitive changes are caught. Locate the lowering logic around
compile_expression, emit_load_const, set_source_range and the
Instruction::BuildTuple / CallFunctionEx emission in compile.rs (also check the
similar spots near the referenced 8292-8293 change) and add tests that assert
the produced bytecode/disassembly matches the expected snapshot for both cases;
run the clean build steps described in the guidelines before committing the
snapshots.