Repository navigation
test_gap_specabi_reassign: reassigned values read back as 0 (untracked, not in gap_snapshot.json) #8006
Description
test_gap_specabi_reassign diverges from node on a macOS arm64 build of 55fd197d5
(+ PR #7999, which cannot affect program output — it only adds a link-time archive check).
$ diff node.out perry.out
3c3
< plain: 99 101 2
---
> plain: 0 0 2
5c5
< captured: 77:2
---
> captured: 0:2
Reassigned values read back as 0. The shape — a value that was written and then reads as
zero, on the specialized-ABI path — is a codegen/spec-ABI defect, not a runtime or link one.
Compile and run both exit 0; it is an output mismatch, so the harness classifies it
parity_fail.
Why it is being filed rather than triaged onto an existing entry
It is not in test-parity/gap_snapshot.json, so nothing is tracking it and nothing can
go red on it. It was found during a full local gap run for #7629
(PERRY_SKIP_BUILD=1 ./run_parity_tests.sh --filter test_gap_, 538 pass / 15 fail /
1 compile-fail / 0 crashed): 14 of the snapshot's 15 entries reproduced, and this was one of
two failures outside it.
Whether it is macOS-only or the Linux snapshot is stale is unresolved — there is no
test-parity/gap_snapshot.macos.json in the tree, so no macOS gap baseline has ever been
recorded, and the required gap shards run only on ubuntu-latest. The first thing to
establish is which of those two it is; that also decides whether a per-host snapshot is
worth committing.
Activity
docs(gc-handoff): link the two defects the #7629 gap run exposed (#8005…
fix(link): refuse a link whose ext wrappers bundle a different tokio (#…
proggeramlug commentedon Aug 14, 2026
Superseded by #8100, which is the same defect with the diagnosis attached.
Same test, same output, same divergence:
What #8100 adds over this report:
let P: Int32Array = new Int32Array(1); … P = [99,101] as any;).call @js_typed_array_getemitted for the plain-array reads, fromcrates/perry-codegen/src/expr/index_get.rs:51-72(native_proof / typed_shape_descriptors: four lowering-independent failures (numeric-coerce on a proven read, missing typed-array fallback record, negative-divisor frem, missing layout-note marker) #7494) usinglocal_type_hint, which keeps the typed-array kind for a reassigned local.P.lengthis correct — the binding really does hold the plain array — so it is only the element reads that are wrong.PERRY_SPECIALIZED_ABI,PERRY_PTR_NUMARRAY_LOCALS,PERRY_PTR_SHAPE_LOCALS,PERRY_INT_VALUED_LOCALS,PERRY_CANONICAL_I32_LOCALS) leave it broken, matchinggc_repsel_matrix.shfailing this row in 22 of 22 arms includingshipped_default.let P: any = …andlet P = …both reproduce; thenew Int32Array(...)initializer stamps the binding and the reassignment never invalidates it.gc-stressis red, which is what blocks promoting that gate to a required context (Promotegc-ratchetto a required context now (precondition met);gc-stressafter #8100 #8101).Your framing here was right and is worth carrying forward: it is a codegen/spec-ABI defect rather than a runtime or link one, and it was invisible because it is absent from
test-parity/gap_snapshot.json, so nothing could go red on it.Closing this one so the work has a single home. Tracking continues in #8100.