[ASDAlexander77]

Summary

Reading an s32[] as number[] silently dropped every change made since the declaration:

let a = [1, 2]; a.push(3); a[0] = 9;
const b: number[] = a;   // was [1, 2], now [9, 2, 3]

castConstArrayToArray (from #344) followed an array load back to the variable's initializer, or the global's initializer region, and rebuilt the array from that literal. Push, element writes, reassignment and sort were all lost. The module-level path had the same fault.

• The trace-back is gone. The new castArrayElementwise handles an array whose elements are integers or floats (nested arrays included) when it is read as number[], a union holding a number, or any[]. It builds a new array of the same length at run time, and a synthesized loop does the element cast as each element is assigned. A real const_array literal still takes the constant path. An s32[] parameter read as number[] now compiles too; it used to be an error.
• NewArray allocates zeroed storage. Under -mm=rc the first store into an element releases what the slot held, so malloc's leftovers were released as references. The conversion loop into any[], (number | string)[] or number[][] crashed on its first element. gc was unaffected because GC_malloc zeroes. This also covers new Array(n) under rc.

The widened array is a copy, so a later write to one is not seen through the other. Converting a literal already worked this way.

Verification

• New test 00array_widen_elements_now.ts (compile, jit, and the rc/none corpus). It covers let, const, reassignment, a parameter, nested arrays, union and any targets, an empty array, copy semantics, and module-level arrays. On main it fails to compile, and the stale-value cases print the old literal.
• Windows Release: 2853/2853 passed.
• Linux (WSL): 2847/2847 passed.
• DefaultLib release jit: 155/155.

Found while testing, not changed here: const nested = [[1, 2], [3]]; nested[1].push(4) crashes in GC_realloc, on main as well.

🤖 Generated with Claude Code