CI cannot see crates/*/tests/*.rs regressions: per-PR runs --lib --bins, and SOURCE_SUITE_MAP is hand-maintained (2 failures beyond #7494)

[proggeramlug]

cargo test -p perry-codegen is red on main (v0.5.1407) with 6 failures across 4 integration suites. All 6 predate the PRs merged today (verified by running the same command on main before and after: identical set).

integer_arithmetic_array_push_omits_inbounds_layout_note_and_barrier
integer_modulo::i32_counter_mod_unsafe_or_nonliteral_divisors_keep_frem
large_local_array_push_inbounds_store_emits_precise_slot_barrier
proven_buffer_and_typed_array_reads_are_numeric_operands
reassigned_typed_array_store_records_runtime_fallback
typed_f64_receiver_method_clone_raw_loads_after_composed_guards

Why this sat unseen

Per-PR cargo-test runs --lib --bins (.github/workflows/test.yml:829) — no tests/*.rs integration suite runs on a PR at all. e2e-scoped runs only suites the diff names, plus a hand-maintained SOURCE_SUITE_MAP that maps all of crates/perry-codegen/src/ to exactly three suites, none of these four.

scripts/ci_e2e_scope.py's own header already names this as the #6037 class: "a source change that regresses an existing suite the diff doesn't name… can land green and sit red for days." This is that, except it is longer than days and nobody has a number for how long, because nothing reports it.

Why it matters beyond these 6

Today two separate PRs (#7698, #7702) each broke a perry-codegen integration test, and in both cases the only way to find out was to run the full suite by hand and diff against a hand-captured main baseline. That is not a workflow — it depends on someone deciding to check. Both were caught; the next one won't be.

The two failures each PR introduced were also different in kind, which is worth recording:

• perf(typed-feedback): stop emitting recording calls into default builds (#7480) #7702 was a genuine assertion that had to change (it required a recording call the PR deliberately stops emitting).
• perf(class-fields): a conforming pointer store skips the layout note (#5094) #7698 was a test that had stopped being able to see its subject — the new conditional split a basic block in three, and the helper sliced text to the first br. The write barrier had not moved; the test just couldn't find it, and no wider text slice would have worked because LLVM emits the join block between the other two.

Suggested

1. Triage the 6 — some may be stale assertions, some may be real.
2. Then either add perry-codegen's suites to the per-PR set, or make SOURCE_SUITE_MAP derive from something that can't silently omit a suite. A hand-maintained map of source dirs to suites has the same failure mode as the MIN_COMPILED=90 floor fixed in gate(gc): make the root-dominance corpus floor a two-sided ratchet #7706: it is correct on the day it is written and nothing tells you when it stops being.

[proggeramlug]

Correction: this partially duplicates #7494 — narrowing it

I filed this without finding #7494, which already documents four of the six and asks the right question about each ("did the lowering legitimately change, or did a proof regress?"):

• proven_buffer_and_typed_array_reads_are_numeric_operands
• reassigned_typed_array_store_records_runtime_fallback
• integer_modulo::i32_counter_mod_unsafe_or_nonliteral_divisors_keep_frem
• integer_arithmetic_array_push_omits_inbounds_layout_note_and_barrier

Those four belong to #7494. It also establishes something I did not: they are lowering-independent (identical with and without PERRY_RS4GC=0, so not part of the #7370 native-roots family) and they reproduce when run alone, so they are not order-dependent either.

What is genuinely new here — two failures #7494 does not list

large_local_array_push_inbounds_store_emits_precise_slot_barrier
typed_f64_receiver_method_clone_raw_loads_after_composed_guards

Both are in the same untested tier. Whether they are older than #7494 or arrived since, I have not established — worth checking, because "the set grew" and "the set was always this size" have different implications for how fast this tier rots.

And the structural half, which #7494 names but does not track

#7494 explains why they went unnoticed; it does not carry the fix. That is what this issue should be:

Per-PR cargo-test runs --lib --bins (test.yml:829), so no crates/*/tests/*.rs suite runs on a PR at all. e2e-scoped runs only suites the diff names, plus a hand-maintained SOURCE_SUITE_MAP (ci_e2e_scope.py:86) mapping all of crates/perry-codegen/src/ to three suites — none of them these.

That map has the same failure mode as the MIN_COMPILED=90 floor fixed in #7706 (a 131-source corpus tolerating 41 silent failures) and the handle-floor regex found in #7709 (blind to sites whose local is named raw): a hand-maintained list of what to check is correct on the day it is written, and nothing tells you when it stops being.

Two of today's PRs each broke a suite in this tier, both caught only by running the full suite by hand and diffing against a same-day baseline. That is not a workflow — it depends on someone deciding to check.

Suggested split: the four → #7494; the two new ones → triage here or move them there once dated; and the CI-coverage gap stays here as the actionable item, since it is what makes the other two issues recur.