⚠️ Potential issue | 🟡 Minor

Typo in type annotation: analyser should be analyzer.

The function's return type annotation uses analyser.Analysis but the import on line 29 is analyzer. This will cause a NameError at runtime if type hints are evaluated.

-def get_analysis() -> analyser.Analysis:
+def get_analysis() -> analyzer.Analysis:

In crates/compiler-core/generate.py around lines 137 to 138, the return type
annotation mistakenly references analyser.Analysis while the module is imported
as analyzer; update the annotation to analyzer.Analysis to match the import (or
change the import to analyser if that was intended) so the type name resolves
correctly; ensure any other occurrences use the same identifier to avoid
NameError.

⚠️ Potential issue | 🔴 Critical

#[repr(u8)] incompatible with pseudo-instruction IDs.

Line 141 merges analysis.pseudos into analysis.instructions, but pseudo-instructions have IDs > 255 (e.g., Jump = 256). Combined with the hardcoded #[repr(u8)] on line 150, this produces an enum that won't compile.

Either:

1. Filter out instructions with IDs > 255:

if opcodes.get(name, {}).get("enabled", True) and analysis.opmap.get(name, 0) <= 255

2. Or change the repr based on max ID:

max_id = max(inst.id for inst in instructions)
repr_type = "u16" if max_id > 255 else "u8"
# Then use {repr_type} in the template

Also applies to: 148-151

crates/compiler-core/generate.py around lines 140-142 and 148-151: after merging
analysis.pseudos into analysis.instructions the enum is generated with a
hardcoded #[repr(u8)] which fails if any instruction id > 255 (pseudo IDs like
256); fix by computing the maximum instruction id after the merge (e.g., max_id
= max(inst.id for inst in analysis.instructions)) and choose repr_type = "u16"
if max_id > 255 else "u8", then inject {repr_type} into the template instead of
the hardcoded u8; alternatively, if you prefer to exclude pseudos from the enum,
filter analysis.pseudos when merging (only include ops with enabled and op id <=
255) before generating the enum.

⚠️ Potential issue | 🟠 Major

Generated imports are incomplete.

The import statement on line 181 only includes Arg, Label, NameIdx, but the generated enum uses additional types from the bytecode module:

• IntrinsicFunction1 (used in CallIntrinsic1)
• IntrinsicFunction2 (used in CallIntrinsic2)
• ResumeKind (used in Resume)

The generator should dynamically collect all oparg types used by instructions and include them in the import:

+def collect_oparg_types(instructions: list[Inst]) -> set[str]:
+    types = set()
+    for inst in instructions:
+        if inst.has_oparg and inst.oparg_typ.name not in ("u32",):
+            types.add(inst.oparg_typ.name)
+    return types

 def main():
     # ... existing code ...
+    oparg_types = collect_oparg_types(instructions)
+    imports = ", ".join(sorted(["Arg", "Label", "NameIdx"] + list(oparg_types)))
     output = rustfmt(
         f"""
     // This file is generated by {script_path}
     // Do not edit!

-    use crate::bytecode::{{Arg, Label, NameIdx}};
+    use crate::bytecode::{{{imports}}};

     {generated}
     """
     )

Committable suggestion skipped: line range outside the PR's diff.

⚠️ Potential issue | 🟡 Minor

Fix typos in documentation comments.

There are two typos in the header comments:

• Line 3: "prooerties" → "properties"
• Line 7: "apear" → "appear"

-# The script will try to detect the properties for each opcode, but it can be useful to override some prooerties. So Ideally,
+# The script will try to detect the properties for each opcode, but it can be useful to override some properties. So ideally,
 # we want to have this file empty because that means that we are fully aligned with CPython's opcodes.
 #
 # enabled : bool
-#   When false the opcode will not apear as a variant.
+#   When false the opcode will not appear as a variant.

crates/compiler-core/instructions.toml lines 3-7: fix typos in the header
comment by replacing "prooerties" with "properties" and "apear" with "appear" so
the documentation reads correctly.

⚠️ Potential issue | 🔴 Critical

Missing imports for oparg types used in enum variants.

The generated code uses IntrinsicFunction1, IntrinsicFunction2, and ResumeKind as generic type parameters for Arg<T> (lines 32-33, 154), but these types are not imported. The import statement only includes Arg, Label, and NameIdx.

The generator script should be updated to include these types in the import statement:

-use crate::bytecode::{Arg, Label, NameIdx};
+use crate::bytecode::{Arg, IntrinsicFunction1, IntrinsicFunction2, Label, NameIdx, ResumeKind};

Or the generator should dynamically determine which oparg types are used and include them in the imports.

In crates/compiler-core/src/bytecode/instruction.rs around lines 1 to 9, the
generated file imports only Arg, Label, and NameIdx but the enum uses oparg
types IntrinsicFunction1, IntrinsicFunction2, and ResumeKind as generic
parameters for Arg later in the file; update the generator so the use statement
also imports those types (or make the generator detect which oparg types are
referenced and include them) so the produced file contains a single import
including Arg, Label, NameIdx, IntrinsicFunction1, IntrinsicFunction2, and
ResumeKind.

⚠️ Potential issue | 🔴 Critical

#[repr(u8)] incompatible with discriminant values exceeding 255.

The enum is declared with #[repr(u8)] but contains multiple variants with discriminant values that exceed the u8 range (0-255):

• Jump { target: Arg<Label> } = 256
• JumpNoInterrupt { target: Arg<Label> } = 257
• LoadClosure { i: Arg<u32> } = 258
• LoadMethod { namei: Arg<NameIdx> } = 259
• LoadSuperMethod { namei: Arg<NameIdx> } = 260
• LoadZeroSuperAttr { namei: Arg<NameIdx> } = 261
• LoadZeroSuperMethod { namei: Arg<NameIdx> } = 262
• PopBlock = 263
• SetupCleanup = 264
• SetupFinally = 265
• SetupWith = 266
• StoreFastMaybeNull { idx: Arg<u32> } = 267

This will fail to compile. The generator should either use #[repr(u16)] or filter out pseudo-instructions with IDs > 255.

Also applies to: 92-96, 114-114, 127-127, 132-134, 143-143, 164-166, 174-174

In crates/compiler-core/src/bytecode/instruction.rs around lines 7-8 (and also
affecting the variant ranges listed at 92-96, 114, 127, 132-134, 143, 164-166,
174), the enum is annotated #[repr(u8)] but contains discriminant values >255
which is invalid; change the representation to #[repr(u16)] or otherwise ensure
generated discriminant values fit in u8 (e.g., filter/remove pseudo-instructions
with IDs >255) so the repr matches the largest discriminant; update the
attribute to #[repr(u16)] if you intend to keep those variants, or adjust the
generator to cap or exclude IDs above 255 to retain #[repr(u8)].