jit: retire the (false,false) walker catch-link arm in flatten_graph

[youknowone]

Retires the last walker-specific exception-CFG adaptation #371 targeted — the follow-up tail to PR #800 (which retired the pcdep regalloc + B1/B2 exception-CFG adaptations and closed #371).

What changed

GraphFlattener::flatten_graph's canraise catch-link loop matched on (last_exception.is_some(), last_exc_value.is_some()) and, for (false, false), flattened the link with the ordinary make_link instead of make_exception_link — a repair for an extra normal/explicit-raise edge the PC-sequential walker could leave after the first slot.

flatten.py:223-233 insert_exits has no such arm: every block.exits[1:] link is lowered through make_exception_link, which already asserts both last_exception and last_exc_value are seeded (flatten.py:161-162; pyre mirrors this assertion in make_exception_link). The payload_shape match is deleted so catch links lower straight through make_exception_link, and an unseeded catch link now fails loud there instead of being silently repaired.

Why it's safe

The arm was unreachable — 0 hits across the full 334-bench synth+top corpus on dynasm (probe-armed build). The 4 benches that previously could not be evaluated (except_star, exception_group_type, exception_subclass_attrs, slots_class_var_conflict — SIGBUS on a stale-LLBC base) all match python3.14 on freshly re-extracted LLBC.

Verification

check.py green on all backends: dynasm 329/329, cranelift 329/329, wasm 326/326.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@youknowone, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 19 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: c7438487-c485-4f67-ba1e-b152aec5ae79

📥 Commits

Reviewing files that changed from the base of the PR and between 3add72a and c3912bd.

📒 Files selected for processing (1)

• pyre/pyre-jit/src/jit/flatten.rs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch miframe

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🤖 Codex parity review

Static analysis of this diff vs the local RPython/PyPy sources (commit c3912bd).
Updated: 2026-07-27T02:25:49.778Z

Files in the reviewed diff

pyre/pyre-jit/src/jit/flatten.rs

1. Regressions to PyPy parity introduced by this patch

None.

2. Other mismatches introduced by this patch

None.

3. Pre-existing mismatches (already present before this patch)

• pyre/pyre-jit/src/jit/flatten.rs:1861 ↔ rpython/jit/codewriter/flatten.py:206: Pyre checks only whether the final operation is -live-; RPython scans backward over all trailing -live- markers and takes the normal edge when the block contains only such markers. An all--live- can-raise block is therefore lowered as a catch block by Pyre but as non-raising by RPython.

4. Structural adaptations

• pyre/pyre-jit/src/jit/codewriter.rs:3229 ↔ rpython/flowspace/flowcontext.py:127: Pyre represents the catch-all with exitcase=None plus seeded exception extravars, whereas RPython preserves exitcase is Exception. Accordingly, pyre/pyre-jit/src/jit/flatten.rs:1884 uses absent llexitcase as the catch-all discriminator. This is a CPython-bytecode graph representation adaptation.
• pyre/pyre-jit/src/jit/flatten.rs:1746 ↔ rpython/flowspace/model.py:641: Pyre supports a one-exit canraise block for an explicit Python raise; RPython requires a can-raise graph block to have at least two exits. This accommodates the CPython-compatible compiler’s explicit-raise shape.
• pyre/pyre-jit/src/jit/flatten.rs:1644 ↔ rpython/jit/codewriter/flatten.py:194: Rust’s typed Insn::Op { opname, args, result } replaces RPython’s heterogeneous instruction tuple, so the overflow rewrite reconstructs fields rather than emitting *line[1:]. The emitted operation shape is equivalent.