Repository navigation
gc-stress gate is dark on main: #6925 left its gap file unregistered, and regressed repsel_ptr_shape_locals under PERRY_PTR_SHAPE_LOCALS=0 #6976
Description
Activity
Cross-ref: the second half of this issue (the
PERRY_PTR_SHAPE_LOCALS=0TypeError) is now tracked as #6984, filed independently by a concurrent investigation that bisected it to the same commit. Suggest this issue stays focused on the gate failure mode — unregistered corpus file ⇒gc_repsel_matrix.shexits 3 before evaluating any cell ⇒gc-stressreports a registration error rather than running the corpus ⇒continue-on-error: true(.github/workflows/test.yml:760) swallows it entirely.That combination is the more durable problem: it is why the regression survived three merges. Removing
continue-on-erroris the smallest fix that makes the next unregistered file loud instead of dark.Re-verified on
main=d4ac65f21in the sweep #7262. Item 2 still reproduces; item 1 appears addressed.Item 1 (unregistered gap file).
test_gap_repsel_proven_this_frozen.tsis now present intest-parity/gc_repsel_corpus.txt, sogc_repsel_matrix.shno longer exits 3 before running anything. Fixed by #6975 as this issue anticipated.Item 2 (Phase 5a regressed its own OFF arm) — unchanged:
PERRY_PTR_SHAPE_LOCALS=0 perry test-files/test_gap_repsel_ptr_shape_locals.ts -o ps ./ps → TypeError: Cannot read properties of undefined (reading 'area') rc=1The last four lines of expected output are missing, exactly as reported. Full evidence on #6984, which is the same defect tracked separately.
One thing this issue should know about its own subject. The gate it is about has had a further, independent darkness problem since:
gc-stressreportedskippedon 12/12 nightlymainruns until #7253 fixed itsif:two hours before this sweep. So between #6975 registering the file and #7253 fixing the trigger, the gate still was not running — item 1 was necessary but not sufficient.And per #7255, four of the six arms
gc-stressruns on a PR currently execute zero copying minors corpus-wide, so even now the job cannot observe the relocating-minor class it was built for.rep_ptr_shape_off— this issue's own red cell — is not among the PR arms in the first place.Closing — one item is fixed and the other is a duplicate, so there is nothing left that is uniquely this issue's.
Item 1 (the dark gate — #6925 left its gap file unregistered) is fixed by #6975. The registration check now covers it.
Item 2 (
PERRY_PTR_SHAPE_LOCALS=0regressingrepsel_ptr_shape_locals) is the same defect as #6984, which describes it in more detail and was still reproducing at its last check. Tracking one defect in two places splits the evidence and guarantees one of them goes stale, so: #6984 is canonical, work continues there.Worth carrying forward to #6984, since it is the more useful half of this issue: the front-door eligibility gate is correctly wired, which means the root cause is most likely in the Phase 3b provenance logic not respecting the kill switch — not in the gate.
- added a commit that references this issue
on Aug 9, 2026
Two problems, both from #6925 (
perf(codegen): repsel Phase 5a — Ptr<Shape> proven this in methods, merged as1a533a3a8). The second one hid the first.1. The Phase 5a gap file was never registered, which breaks the whole matrix gate
#6925addedtest-files/test_gap_repsel_proven_this_frozen.tsbut did not add it totest-parity/gc_repsel_corpus.txt. That is the omission the manifest exists to catch, andscripts/gc_repsel_matrix.shenforces it by exiting 3 before running anything:So
gc-stresshas been failing onmainfor every PR since #6925 merged — and because the script bails up front, it reported the registration error rather than running the corpus. The gate has been dark, not green.(Registration is one line; it is included in #6975 so the gate starts running again.)
2. Phase 5a regressed its own OFF arm:
repsel_ptr_shape_locals × rep_ptr_shape_offWith the gate running again, a genuine red cell appears — and it is Phase 5a's own escape hatch:
The program dies partway: the last five lines of expected output are missing.
Bisect (all
--profile perry-dev, macOS arm64, pinned Node 26.5.0)8327ced52(parent of #6925)1a533a3a8(#6925)TypeError … reading 'area'760db2fd8(currentmain)So it is #6925, and it is not #6972 — a full
--arms allrun on the #6972 branch (based on8327ced52) was 361/361 byte-exact with FAIL=0, which included this exact cell.Why this shape matters
PERRY_PTR_SHAPE_LOCALS=0is the documented escape hatch for the Phase 3b / 5a representation. An arm that turns a representation off should be the safest configuration in the matrix; if the compiler only works with the optimization enabled, the escape hatch is not a bisection tool any more. Thereading 'area'shape suggests a proven-thisclone (or its dispatch) is still being selected, or a guard-free path is still being taken, when the gate says it should not be — i.e. the Phase 5a eligibility decision and thePERRY_PTR_SHAPE_LOCALSgate are not reading the same switch.Triage note
#6975 registers the corpus file (so the gate runs at all) and adds a triage entry for this cell pointing at this issue, so the table is honest rather than dark. Please retriage/remove that entry once this is fixed — it is not meant to be permanent.
Related: #6954 (the matrix + its enforcement point), #6950, #6951.