codegen: typed-array element loop reads wrong sum when object has a sibling Array field

[proggeramlug]

Summary

Summing a TypedArray field of an object with an element-index for loop returns the wrong result when the object also has a plain-Array field. Reproduces with a single object, synchronously, with no async and no GC pressure — so it is a codegen bug, not a GC bug. In simple cases it's a deterministic wrong answer; under retention/allocation it becomes non-deterministic (mis-reads varying adjacent memory), which is how it surfaced while validating the moving GC.

Repro (deterministic)

const n = { id: 5, payload: [1, 2, 3, 4], buf: new Uint32Array([10, 20, 30]) };
let s = 0;
for (const p of n.payload) s += p;                       // 10
for (let i = 0; i < n.buf.length; i++) s += n.buf[i];    // +60
console.log(s);   // node: 70   |   Perry: 10   (the buf loop contributes 0)

Key observations

• Direct field access is CORRECT — n.buf.length is 3, n.buf[0..2] are 10,20,30, n.buf.constructor.name is Uint32Array, and this holds with the typed array as the only field, first field, or after the array field. So the object literal stores the typed array fine.
• The bug is specifically the element-index loop for (let i=0; i<n.buf.length; i++) ... n.buf[i] reading a typed-array field of an object that also has an Array field. Perry’s packed-numeric loop optimizations (crates/perry-codegen/src/stmt/loops.rs — match_packed_f64_versioned_loop / packed i32/u32 paths, typed-feedback guards) emit raw element loads; a guard/alias misfire when the receiver object has a sibling Array field is the likely cause.
• Control cases that are CLEAN: {id, a:number[], b:number[]} (two plain arrays); {id, buf} (typed array only); reading n.buf[i] directly rather than in the summing loop.

Impact

Silent wrong results for a common pattern (objects holding both a JS array and a typed array, iterated by index). Because the mis-read can also read/write adjacent heap memory, it corrupts the heap and makes any subsequent collector (moving or not) fragile — this is what made a moving-GC stress test crash; the GC was choking on a heap this bug had already corrupted.

Next step

Localize with --trace hir --focus on the loop and --trace llvm; check the packed-numeric-loop guard/versioning when the loop receiver is a typed-array field on an object with other pointer fields.

[proggeramlug]

Fixed in PR #6134 (commit 657b015). Root cause: a member receiver (n.buf[i]) with a loop-variable integer index was lowered via lower_legacy_array_index_get, which inline-reads the value as a plain ArrayHeader (gc_type at handle-8, raw f64 slot at handle+8+i*8) — but a small typed array is off-heap with no GcHeader, so those reads are garbage. Fix routes the case through the typed-feedback-guarded path (guard rejects non-plain arrays → boxed fallback that dispatches typed arrays; plain arrays keep the fast path). Case matrix now matches Node; the moving-GC stress test that crashed ~4/5 runs is 0/6; no regressions. A separate smaller non-GC nondeterminism in the heaviest mixed repro remains — filed separately.

[proggeramlug]

Fixed in #6134 (commit 657b015): the member typed-array loop read now routes through the typed-feedback-guarded path instead of the off-heap-unsafe legacy inline reader. Case matrix matches Node; the moving-GC stress that crashed ~4/5 is 0/6.