test_gap_gc_alloc_point_no_move.ts does not finish compiling on main (>23 min); #7682 coverage may be dark #8906

Summary

test-files/test_gap_gc_alloc_point_no_move.ts (310 lines) does not finish compiling on current main. Observed at 23 minutes at 100% CPU under the gap harness before I killed it, and it exceeds a 300 s cap in a standalone A/B.

This test is the #7682 regression test — it guards against an allocation-point evacuating minor relocating objects still named by live registers, which produced a silently wrong number (1708662 instead of 1708840) with no crash and no diagnostic. It is not in test-parity/gap_snapshot.json's exceptions map, i.e. it is expected to pass.

Evidence

Same input file, two release compilers each pinned to its own PERRY_RUNTIME_DIR, hard-killed at the cap:

Both compilers built with cargo build --release -p perry -p perry-runtime-static -p perry-stdlib-static; binary and .a timestamps verified to post-date each checkout. The four-arm result attributes this to main and rules out both PR #8897 and the auto-optimize path.

Why this matters

A test that cannot compile is not testing anything. If this is reaching CI as a timeout that gets classified into a non-failing bucket, then the #7682 coverage is dark while appearing present — the "gate runs but its subject never did" shape from CLAUDE.md's four-ways-a-gate-cannot-fail list.

Not yet established

• When it regressed. Not bisected. If this test ever ran quickly, the bisect is the next step; if it was always this slow, then the question is how it passes in CI's fast-mode shards at ~1.5 s/test.
• Where the time goes. Not profiled. The file is a tree-walking interpreter for a small functional language, so deeply nested expressions are a plausible trigger for superlinear behaviour in a compiler pass, but that is a hypothesis, not a measurement.