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:
| compiler |
env |
result |
main @ 7c9f60169 |
(none) |
TIMEOUT > 300 s |
main @ 7c9f60169 |
PERRY_NO_AUTO_OPTIMIZE=1 |
TIMEOUT > 240 s |
| PR #8897 merged onto main |
(none) |
TIMEOUT > 240 s |
| PR #8897 merged onto main |
PERRY_NO_AUTO_OPTIMIZE=1 |
TIMEOUT > 240 s |
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.
Summary
test-files/test_gap_gc_alloc_point_no_move.ts(310 lines) does not finish compiling on currentmain. 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:main@7c9f60169main@7c9f60169PERRY_NO_AUTO_OPTIMIZE=1PERRY_NO_AUTO_OPTIMIZE=1Both compilers built with
cargo build --release -p perry -p perry-runtime-static -p perry-stdlib-static; binary and.atimestamps verified to post-date each checkout. The four-arm result attributes this tomainand 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