Reviewing files that changed from the base of the PR and between b704f42 and ea4e001.

• .github/copilot-instructions.md
• crates/codegen/src/compile.rs
• crates/codegen/src/error.rs
• crates/compiler-core/src/bytecode.rs
• crates/vm/src/exceptions.rs
• crates/vm/src/frame.rs

.github/copilot-instructions.md (1)

76-82: Clean-build instructions for bytecode edits are clear and consistent

The added section gives a precise, reproducible clean command for bytecode changes and fits well with the surrounding Lib/ guidance. No issues from a tooling or safety perspective.

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

91-92: New BreakContinueReturnInExceptStar error variant is wired correctly

The enum variant and its Display arm are added consistently with existing error types, with a clear diagnostic string that will surface nicely at compile time. No structural or behavioral issues.

Also applies to: 153-158

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

868-871: SetExcInfo opcode is cleanly integrated into the bytecode model

• Adding SetExcInfo at the end of Instruction and updating LAST_INSTRUCTION keeps the marshaling range consistent.
• stack_effect returns 0, matching the “peek‑only” semantics.
• Disassembly uses SET_EXC_INFO, which aligns with the other mnemonics.

No additional wiring issues spotted.

Also applies to: 875-875, 1749-1750, 1982-1983

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

1583-1617: LGTM: Break statement validation for except blocks.*

The control flow correctly validates that break cannot occur inside an ExceptionGroupHandler block before reaching a loop. The Result<Option<BlockIdx>, ()> approach cleanly handles the three cases: found loop, no loop, and forbidden context.

---

1620-1657: LGTM: Continue statement validation mirrors break handling.

The implementation correctly mirrors the break validation logic, using fb_block (loop start) for continue vs fb_exit (loop end) for break.

---

1665-1676: LGTM: Return statement check in except blocks.*

Unlike break/continue which need to find a loop first, return is unconditionally forbidden anywhere within an ExceptionGroupHandler, and this implementation correctly checks for any such handler in the fblock stack.

---

2156-2426: The except* implementation correctly handles exception group matching, handler execution, exception accumulation, and final reraise. All ListAppend index calculations are correct and properly target the exception results list based on the documented stack states.

Reviewing files that changed from the base of the PR and between ea4e001 and d8cda04.

• Lib/test/test_except_star.py is excluded by !Lib/**

• .github/copilot-instructions.md
• crates/codegen/src/compile.rs
• crates/codegen/src/error.rs
• crates/compiler-core/src/bytecode.rs
• crates/vm/src/exceptions.rs
• crates/vm/src/frame.rs

• crates/codegen/src/error.rs
• crates/vm/src/frame.rs

• GitHub Check: Run snippets and cpython tests on wasm-wasi
• GitHub Check: Run snippets and cpython tests (windows-latest)
• GitHub Check: Run snippets and cpython tests (ubuntu-latest)
• GitHub Check: Run snippets and cpython tests (macos-latest)
• GitHub Check: Run rust tests (windows-latest)
• GitHub Check: Run rust tests (macos-latest)
• GitHub Check: Run tests under miri
• GitHub Check: Run rust tests (ubuntu-latest)
• GitHub Check: Check the WASM package and demo
• GitHub Check: Check Rust code with clippy
• GitHub Check: Ensure compilation on various targets

crates/vm/src/exceptions.rs (10)

2436-2468: LGTM!

The validation logic correctly enforces except* semantics: match types must be BaseException subclasses but cannot be ExceptionGroup/BaseExceptionGroup. Error messages are clear and match Python's behavior.

---

2484-2485: Good addition of validation.

The early validation ensures that except* handlers reject ExceptionGroup types, which correctly implements Python 3.11+ semantics.

---

2513-2519: Defensive type checking added.

This validation ensures that user-defined split() methods return the correct type, catching errors early with a clear message.

---

2548-2559: Correct handling of edge cases.

The early return for empty lists and special handling for naked (non-group) exceptions correctly implements the except* semantics where only one except* clause can execute for a naked exception.

---

2569-2575: Good use of leaf ID comparison.

Using is_exception_from_orig to distinguish raised from reraised exceptions is a robust approach that relies on object identity rather than mutable metadata.

---

2582-2603: Correct projection and combination logic.

The projection preserves the original nested structure for reraised exceptions, and the combination logic correctly handles single vs. multiple exceptions, matching Python's except* behavior.

---

2606-2624: LGTM!

The leaf ID comparison approach correctly identifies reraised exceptions by checking if all of the exception's leaf IDs are present in the original group, relying on the fact that split() preserves leaf exception identity.

---

2626-2650: LGTM!

The recursive collection correctly identifies leaf exceptions by checking if an exception is not an exception group, and safely traverses nested structures using if-let chains.

---

2652-2672: LGTM!

The projection function correctly collects leaf IDs from the keep list and delegates to split_by_leaf_ids for the actual recursive splitting, maintaining a clean separation of concerns.

---

2674-2712: LGTM!

The recursive splitting correctly preserves the nested structure using the derive() method. Per the learnings, derive() intentionally creates BaseExceptionGroup instances rather than preserving the original exception class type, which is a deliberate design decision.

Based on learnings, this design differs from CPython but is intentional in RustPython.

.github/copilot-instructions.md (1)

76-82: Clean-build instructions look good and match prior suggested workflow

The new “Clean Build” snippet is accurate for forcing a rebuild after bytecode instruction changes (wiping rustpython build artifacts and Python bytecode). No issues from a tooling or safety perspective; this should help avoid stale-instruction failures.

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

868-876: SetExcInfo opcode is wired consistently (enum, marshaling, stack effect, disassembly)

The new SetExcInfo instruction is correctly integrated:

• Added as the last Instruction variant and LAST_INSTRUCTION updated, keeping TryFrom<u8>/marshaling valid.
• stack_effect returns 0, matching the “does not pop the value” behavior.
• Disassembler prints SET_EXC_INFO, consistent with other op names.

No issues spotted here.

Also applies to: 1749-1750, 1982-1983

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

1665-1676: Return is correctly disallowed anywhere within an except handler frame*

The added check for FBlockType::ExceptionGroupHandler before emitting a return:

• Ensures return is rejected anywhere in the dynamic extent of an except* handler (including inside nested loops), which aligns with CPython’s semantics.
• Still permits return in the try body, else, finally, and in nested functions defined inside an except* since those have their own CodeInfo/fblock stacks.

This is a good, minimal way to enforce the restriction using the existing fblock mechanism.

---

2156-2423: except compilation flow matches CPython’s multi-block design and maintains stack invariants*

The reworked compile_try_star_except looks internally consistent and closely follows CPython’s strategy:

• Stack protocol:

  • At handler entry, [exc] → [orig, list, rest] via BUILD_LIST(0) and COPY(2), giving a stable orig and mutable rest plus an aggregation list.
  • For each handler, CHECK_EG_MATCH transforms [orig, list, rest, type] into [orig, list, new_rest, match], and all subsequent paths (no match, normal handler completion, and handler raising) end with [orig, list, new_rest], ready for the next handler.
  • After the last handler, ListAppend { i: 0 } appends the final rest to the list, and PrepReraiseStar(orig, list) is invoked with exactly two arguments, returning a single result.

• Handler semantics:

  • Unparenthesized tuple types and except* without a type are rejected with clear SyntaxErrors during codegen.
  • SetExcInfo is issued before running the handler body so bare raise re-raises the correct match.
  • Handlers are wrapped in an inner SetupExcept with a dedicated handler_except_block:
    • Normal completion: no new exception; match is dropped and None is appended with ListAppend { i: 1 }.
    • Raised in handler: the raised exception is appended with ListAppend { i: 2 } and match is dropped.
  • Name binding (as name) is cleaned up in both normal and exceptional paths by resetting to None and deleting the variable, matching standard except behavior.
  • FBlockType::ExceptionGroupHandler is pushed only around the handler body and popped immediately afterward, giving break/continue/return the necessary context while not leaking into surrounding code.

• Reraise / no‑reraise paths:

  • The result is not None test uses identity (is not None) via IsOp(Invert::Yes), and if true branches to a Raise { kind: Raise } with result still on the stack—effectively raise result.
  • When result is None, result is popped and the original try* exception is cleaned up with PopException, after which (if a finally exists) the code performs PopBlock + EnterFinally and jumps to a shared end_block.

• Else / finally integration:

  • The try-else path is unchanged structurally: on success, SetupExcept is popped, else_block is executed, and for a present finally we again use PopBlock + EnterFinally before jumping to end_block.
  • end_block serves as a common join point for “no re‑raise” and “else” paths; finally_block is chained after it and runs finalbody followed by EndFinally.

Given how subtle these flows are, especially with nested except*, finally, and different ways of raising (bare raise, raise e, new exceptions from handlers), it’s worth making sure tests cover:

• try/except* with and without else/finally,
• handlers that both handle and re-raise parts of an exception group,
• bare raise inside except*,
• and combinations of multiple except* handlers.

Structurally, though, this implementation looks sound and matches the expected stack behavior.