release blocker: stable packed loop reads stale forwarded array after cross-call growth

[proggeramlug]

Release blocker

The full release CI run for v0.5.1519 fails deterministically in:

• cargo-test-perry (8/8)
• issue_5139_object_arraylike_method_dispatch::any_typed_real_arrays_keep_array_mutator_semantics

Observed output:

grow: 1000 1000 165171

Expected sum: 499500. Sampled array values (0, 1, 2, 99, 500, 999) are correct, so storage is intact and the optimized reduction is wrong.

Reproduction

RUST_TEST_THREADS=1 cargo test -p perry \
  --test issue_5139_object_arraylike_method_dispatch \
  any_typed_real_arrays_keep_array_mutator_semantics -- --exact --nocapture

Reproduced independently on perrymaster.skelpo.net at release SHA 259cf8b68dc1303cc4119595f96d458a52af8c4e.

Bisect

Automated exact compiler/runtime bisect:

• good: da0eefbf99a80da0b00020c0ae1c4bb88a1147ca
• first bad: 57926713b078df354d7cf76ff11eaa18d5de76fb (perf(codegen): reduce accumulators earn the packed fast clone's numeric proof — s += arr[i] at node parity (was 5.3×) #9060)

The array is grown across a call boundary and the caller retains a forwarding stub. js_packed_arraylike_loop_guard follows that stub and validates the live target, but the ordinary-local stable-packed path discards the live address and reloads/de-tags the stale local for direct fast-clone reads. #9060 makes that clone reachable for the reduction by classifying js_shadow_slot_set as call-safe.

Required fix

Use js_packed_arraylike_loop_guard_live for ordinary-local admission as well as captured receivers, and feed its returned live receiver address to the fast clone. Retain the generic slow clone on a zero result. Update IR assertions to expect the stronger live guard.

Before merging/releasing, verify:

• the exact issue_5139 test above;
• all three issue_8690 versioned-loop tests, including three live-guard calls in the read-only IR fixture;
• issue_8655 and issue_8773 packed-loop IR/runtime coverage;
• quick pre-tag checks.

[proggeramlug]

Stale — closing.

Verified green on release candidate 01463b81610f089cc566011d16ea5e5b08ec70a8 (run 33346563641): all 8 cargo-test-perry shards pass and compiler-output-regression passes. No fix for this issue appears in main's history, so it was resolved incidentally by other merges rather than by a targeted change.

The subject was confirmed live, not skipped — e.g. #9117's any_typed_real_arrays_keep_array_mutator_semantics appears 3× in shard 2's log (shard assignment moves between runs) and that shard passed.

Reopen if it resurfaces on a later candidate.

[proggeramlug]

Reopening — I closed this prematurely and the evidence for closing was too weak.

It is failing again on release candidate 83754818ea (full-tier run 33372993990, cargo-test-perry (4/8)), with output byte-identical to the original report:

any-typed array push must grow correctly across a call boundary (got: grow: 1000 1000 165171

Same wrong sum — 165171 rather than 499500.

Why the closure was wrong

I closed this because all 8 cargo-test-perry shards were green on the previous candidate 01463b8161, and I confirmed the test genuinely ran and passed there (shard 2 printed test any_typed_real_arrays_keep_array_mutator_semantics ... ok — not merely present in the log, actually ok).

That observation was correct but the inference was not. This issue's own diagnosis says the sampled array values are correct and "the optimized reduction is wrong" — an optimizer bug. Its visibility depends on codegen decisions that shift with unrelated merges, so it can pass on one candidate and fail on the next with no change to the code under test. For this class, one green run is not evidence of a fix; only a root-caused change is.

Nothing between 01463b8161 and 83754818ea targeted this bug, so it was masked rather than fixed.

Impact

cargo-test-perry is in full-suite-gate's needs, so this blocks the v0.5.1519 release.

Reproduction

RUST_TEST_THREADS=1 cargo test -p perry \
  --test issue_5139_object_arraylike_method_dispatch \
  any_typed_real_arrays_keep_array_mutator_semantics -- --exact --nocapture

Note when reproducing: because visibility is optimization-dependent, a local pass does not clear it. Confirm against the candidate SHA and the same profile CI uses.

[proggeramlug]

Additional data for whoever picks this up.

It is not intermittent in the ordinary sense — it is optimization-state dependent. Observed on release candidates:

candidate	verdict
01463b8161	... ok (shard 2)
83754818ea	FAILED (shard 4), output byte-identical to the original report

Nothing between those two commits targeted this defect, and the crate under test was unchanged. So the difference is which optimizer decisions the surrounding tree produces, exactly as the original diagnosis implies ("sampled array values are correct … the optimized reduction is wrong").

Practical consequence for anyone verifying a fix: a green run proves nothing on its own here. A local pass, or a pass on one candidate, is consistent with the bug being present and merely masked. Only a root-caused change should close this — I closed it on a single green run and had to reopen it.

Note the shard number moves between runs (2 → 4), so grep the whole cargo-test-perry matrix for the test name rather than a fixed shard.