[ASDAlexander77]

Fixes fuzzer bug G1 (#646): under gc and none, a closure over a const read out of a field saw a later write to that field.

let n15: N = mk(3);
const v16: V = n15.v;
n15.v = mv(2);
const c = (): number => v16.a[0];
print("closure", c());      // gc/none printed 2; the answer is 3 (rc was right)

Why

A const read out of a field, an element or a global is folded into the read, so it has no storage of its own under gc and none. Under rc it does (processConstRef), which is why rc was right. A by-value capture used GetReferenceFromValue, which for a folded read is the place it was read from, and CaptureOpLowering dereferenced that place when the closure was made, after the overwrite.

Fix

A capture goes through a reference only when that reference is the variable's own storage: a ts.Variable, a parameter, or a captured cell. Anything else captures the value itself. Read-write captures (by reference) are unchanged.

Tests

tests/00closure_const_read.ts: a closure over a const read out of a field, an element and a global, each overwritten before the closure is made. It fails under gc and none on main. It runs compiled, under JIT, and in the rc/none corpus.

The interface-field variant (const v = ix.v) is left out of the test until #651 merges. Without #651 that const has no count under rc (R7), and capturing the value it actually read turns R7's dangling const into a crash. Before this change the capture happened to re-read the live new value.

Verification

• ctest -C Release: Windows 4982/4982, WSL Linux 4964/4964.
• Replaying the fuzzer's repros on Linux: G1-closure-const-field now matches gc in every model.
• mm_fuzz.py --jobs 10 run --count 500 --seed 1: only the 3 known own failures (R1, O4).

🤖 Generated with Claude Code