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

736-742: ⚠️ Potential issue | 🟡 Minor

Limit the enclosing import scan to module/class scopes.

Lines 736-742 currently treat any imported name in an outer function as if it were a module/class-scope import. For def outer(): import m; def inner(): return m.f(), inner will take the imported-name path again even though m is a closure-captured local, not a global/module binding.

Possible fix

-        self.symbol_table_stack.iter().rev().skip(1).any(|table| {
-            table
-                .symbols
-                .get(name)
-                .is_some_and(|sym| sym.flags.contains(SymbolFlags::IMPORTED))
-        })
+        self.symbol_table_stack.iter().rev().skip(1).any(|table| {
+            matches!(table.typ, CompilerScope::Module | CompilerScope::Class)
+                && table
+                    .symbols
+                    .get(name)
+                    .is_some_and(|sym| sym.flags.contains(SymbolFlags::IMPORTED))
+        })

🤖 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 736 - 742, The enclosing-scope
scan in compile.rs currently treats any imported symbol found in an outer
function as a module-level import; change the iteration over
self.symbol_table_stack to only consider module- or class-level scopes (e.g.,
stop/skipping once you hit a non-module/class scope) instead of scanning all
outer tables. Concretely, replace the current .iter().rev().skip(1).any(...)
with a loop or iterator that filters tables by their scope kind (check the
symbol table's scope/kind field or method on the symbol table) and only checks
tables where the scope is Module or Class before testing
symbols.get(name).is_some_and(|sym| sym.flags.contains(SymbolFlags::IMPORTED)).
This ensures closure-captured imports in outer functions are not treated as
module/class imports.

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

2036-2050: ⚠️ Potential issue | 🟡 Minor

Comment claims a check that isn't implemented.

The comment on line 2038 states "AND the return instructions have no explicit line number (lineno <= 0)", but the is_return_block check below (lines 2039-2047) only verifies the block length and instruction types—it doesn't check lineno_override or location.line.

If the lineno check is required for CPython parity, please add it:

Possible fix if lineno check is needed

     let is_return_block = last_insts.len() == 2
         && matches!(
             last_insts[0].instr,
             AnyInstruction::Real(Instruction::LoadConst { .. })
         )
         && matches!(
             last_insts[1].instr,
             AnyInstruction::Real(Instruction::ReturnValue)
-        );
+        )
+        && last_insts[0].lineno_override.unwrap_or(last_insts[0].location.line.get() as i32) <= 0;

Otherwise, please update the comment to accurately reflect what the code checks.

🤖 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 2036 - 2050, The comment claims the
code should only apply when the return instructions have no explicit line number
(lineno <= 0) but the is_return_block predicate only checks instruction count
and types; update the predicate in the block containing last_insts and
is_return_block to also verify the first instruction's line info (e.g., check
last_insts[0].lineno_override <= 0 or last_insts[0].location.line <= 0 as
appropriate for this IR) so the condition matches the comment, or if that lineno
check is not required for parity, change the comment to accurately describe that
is_return_block only checks length and instruction kinds; reference last_insts,
is_return_block, lineno_override and location.line to locate the exact variables
to modify.

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

289-311: ⚠️ Potential issue | 🔴 Critical

The ResumeType::AfterYield encoding is incomplete for CPython 3.14 compatibility.

According to CPython 3.14's RESUME opcode specification, the oparg encoding uses the lowest 2 bits for the location (0–3) and bit 2 (value 4) for except-depth. This yields valid values 0–7:

• 0–3: Base locations (AtFuncStart=0, AfterYield=1, AfterYieldFrom=2, AfterAwait=3) at except-depth 0
• 4–7: Same locations at except-depth 1

Your current mapping encodes AfterYield as 5 (which is 1 + 4, representing AfterYield at except-depth 1), but the code doesn't handle AfterYield at except-depth 0 (oparg=1). Additionally, it lacks mappings for AtFuncStart (4), AfterYieldFrom (6), and AfterAwait (7) at except-depth 1.

Either the encoding needs to distinguish except-depth explicitly in ResumeType, or the current hardcoded mappings should reflect that reality.

🤖 Prompt for AI Agents

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

In `@crates/compiler-core/src/bytecode/oparg.rs` around lines 289 - 311, The
mapping for ResumeType must support CPython 3.14's 3-bit oparg (low 2 bits =
location 0–3, bit 2 = except-depth), so update ResumeType and its conversions:
change the enum (ResumeType) to carry an except_depth flag (e.g., a bool or u8)
or add separate variants that include except-depth, then modify impl From<u32>
for ResumeType to decode value & 0b11 into
AtFuncStart/AfterYield/AfterYieldFrom/AfterAwait and (value & 0b100) >> 2 into
except-depth; likewise update impl From<ResumeType> for u32 to emit (location as
0..3) | (except_depth << 2) and preserve Other(v) for unknown values. Ensure all
places referencing ResumeType are adjusted to the new shape.