Repository navigation
e2e-scoped: any_call_result_trim_emits_string_tag_dispatch has been failing on main since ~2026-08-10, reddening unrelated PRs #8549
Description
Summary
crates/perry-codegen/tests/argless_builtin_extra_args.rs::any_call_result_trim_emits_string_tag_dispatch fails on clean main and has done for at least nine days. It is currently reddening e2e-scoped on every open PR that touches perry-codegen, where it reads as that PR's fault.
Proof it is not any PR's fault
Fresh worktree at origin/main (7c22189aa), nothing applied:
failures:
any_call_result_trim_emits_string_tag_dispatch
test result: FAILED. 3 passed; 1 failed; 0 ignored
The assertion is:
assert_eq!(ir.matches("= call double @perry_fn_schema_ts__make(").count(), 2,
"the receiver must be evaluated once in the init body (plus the generated extern wrapper)");Observed count is 1, expected 2. The fixture is make().trim() where make is an imported extern returning Any.
Bisect so far
| commit | date | result |
|---|---|---|
debefa55c |
2026-08-10 | PASS |
8bfdac447 |
2026-08-19 | FAIL |
6173ff9f6 |
2026-08-20 | FAIL |
8d1cca158 … 7c22189aa |
08-20/21 | FAIL |
497 commits in the good→bad window. An automated git bisect run was started and paused when free disk fell to 7.7 GiB — ENOSPC manufactures false failures, so a paused bisect is better than a wrong answer. It needs roughly nine build-and-test rounds with ~10 GiB headroom.
Why nobody noticed
crates/*/tests/*.rs run per-PR only when the diff names them (e2e-scoped, see scripts/ci_plan.py). A break in this suite is therefore invisible on main and only surfaces on whichever PR happens to touch perry-codegen — wearing that PR's name.
This has already cost real time: it was mis-attributed to #8540, and an agent was dispatched to "fix" a receiver-evaluation bug that PR did not introduce. #8537, #8543 and #8525 carry the same inherited red.
Why it matters beyond CI noise
The count pins how many times the receiver expression is evaluated, and the receiver is a call. A count of 1 instead of 2 means the receiver is no longer materialized in the init body before the string-tag dispatch. If that reflects real emitted code rather than a changed wrapper shape, a side-effecting receiver's semantics have shifted. That needs answering before the assertion is adjusted — do not "fix" this by editing the expected count.
Suggested approach
- Finish the bisect with adequate disk (
git bisect start; git bisect bad <main>; git bisect good debefa55c, thengit bisect runon that one test). - Diff the emitted IR for the fixture at the culprit commit against its parent — faster than reading the pass.
- Decide from JS semantics whether the new evaluation count is correct. If it is, prove observable behaviour is unchanged with a runtime fixture whose
make()has a side effect, then update the assertion with that reasoning recorded. If it is not, fix the lowering.
Related
The same structural gap — a suite that only runs when a PR happens to touch it — is worth a separate look: a main-only sweep that runs the integration suites unconditionally would have caught this on the day it landed.
Activity
proggeramlug commentedon Aug 21, 2026
A second, independent main breakage:
test_gap_eval_as_valueWhile attributing PR reds I found the same sibling-evidence pattern for a gap-suite failure.
test_gap_eval_as_value: pass -> crashis reported by five independent PRs:Five unrelated PRs — bun:sqlite, child_process, wasm-bindgen, process.argv, and a GC holder census — cannot plausibly break the same eval test in the same way. As with the
e2e-scopedfailure this issue was opened for, the base is the suspect, not the PRs.Worth noting these are two different suites failing for the same structural reason: a break on
mainsurfaces on whichever PR happens to run the affected shard, wearing that PR's name. Right nowmainhas at least two such breakages, and between them they are reddening every open PR.I have not yet run
test_gap_eval_as_valueagainst a cleanmainbuild to close the loop — that needs a fresh compiler build, and I would rather report the concurrence now than sit on it. It should be verified the same way thee2e-scopedone was: build cleanmain, run that single test, and confirm it crashes with no PR applied.Recommend widening this issue (or opening a sibling) to cover both, because the fix for the structural problem is the same: the integration and gap suites need an unconditional
main-only sweep. Today they run per-PR only when a diff names them, so nothing observesmaindirectly, and a breakage can sit for days — thee2e-scopedone has been there since somewhere between 2026-08-10 and 08-19 — while quietly failing every contributor's PR.proggeramlug commentedon Aug 22, 2026
Closed by #8566, which fixed all five failing targets —
argless_builtin_extra_args(4),native_proof_regressions(274),loop_safepoint_purity(8),temp_root_operand_temporaries(19), andperry-api-manifest.Two notes for the record.
The
argless_builtin_extra_argsassertion moved from 2 to 1, which is what this issue warned against — but correctly. The invariant text still reads "the receiver must be evaluated exactly once"; only the accounting for the__perry_wrap_extern_*wrapper changed, because #8383 dropped it. The semantic guarantee about a side-effecting receiver is intact.The second gap this issue raised —
test_gap_eval_as_value: pass -> crashreported by five independent PRs — is not addressed here and should stay open or move to its own issue.The structural problem remains the real one: these suites run per-PR only when a diff names them, so a break on
mainis invisible until it surfaces under someone else's PR. This one sat since roughly 2026-08-10 and cost a mis-attribution plus an agent dispatched to fix a bug the PR had not introduced. Amain-only unconditional sweep would have caught it the day it landed.proggeramlug commentedon Oct 12, 2026
Fixed by #8566 (merged 2026-08-22), which closed the e2e-scoped drift on all five failing targets. The separate test_gap_eval_as_value crash mentioned in the thread should be filed on its own if it still reproduces.