12552e125d
Two silent-miscompile codegen fixes:
0083 — named-const array dimension. `TypeResolver.resolveCompound`'s array
arm resolved the dimension with `if int_literal ... else 0`, so a named const
(`N :: 16; [N]T`) hit the silent `else 0`: the array became 0-length / 0-byte
and element access ran out of bounds (garbage for scalars, bus error for
slice/pointer/struct elements). The arm now delegates the dimension to
`inner.resolveArrayLen` (symmetric with `inner.resolveInner` for the element).
The stateful `Lowering.resolveArrayLen` evaluates it as a compile-time integer
across the comptime-constant / generic-value / module-global const tables and
emits a diagnostic — no fabricated length — when it isn't one.
0084 — `.[...]` literal passed directly as a call arg. `lowerArrayLiteral`
always yields an aggregate array value; the array→slice conversion is the
caller's job. The local-bound var-decl path did it, but the call-arg coercion
path had no array→slice arm, so `classify([N]T, []T)` returned `.none` and the
raw array was passed where a slice was expected (callee read its {ptr,len}
header off the wrong bytes → 0 / garbage / segfault). `classify` now returns a
new `.array_to_slice` plan for same-element `[N]T → []T`, and `coerceToType`
emits the existing `array_to_slice` op — identical to the local-bound path.
Regressions (fail-before/pass-after demonstrated on the pre-fix compiler):
examples/0140-types-named-const-array-dim.sx (s64 + string + struct elems)
examples/0141-types-slice-literal-direct-call-arg.sx (string + []s64)
Gate: zig build, zig build test, bash tests/run_examples.sh (387 passed).
Issues 0083 and 0084 marked RESOLVED.
2.4 KiB
0083 — fixed array with a named-constant dimension is miscompiled
RESOLVED. Root cause:
TypeResolver.resolveCompound's array arm resolved the dimension withif (length.data == .int_literal) ... else 0— a named const (N :: 16) hit the silentelse 0, so[N]Tbecame a 0-length / 0-byte array and element access ran out of bounds (garbage for scalars, bus error for slice/pointer/struct elements). Fix: the array arm now delegates the dimension toinner.resolveArrayLen(symmetric withinner.resolveInnerfor the element type). The statefulLowering.resolveArrayLenevaluates the dimension as a compile-time integer across the comptime-constant, generic-value, and module-global const tables, and emits a diagnostic (no fabricated length) when it isn't one. Files:src/ir/type_resolver.zig,src/ir/lower.zig,src/ir/type_bridge.zig. Regression:examples/0140-types-named-const-array-dim.sx(s64 + string + struct element types).
Symptom
A fixed array whose dimension is a module-global integer constant (N :: 16; a : [N]T) miscompiles element access: reads/writes compute a wrong address.
With s64 elements a[0] returns GARBAGE (silent); with slice/pointer element
types ([N]string) it Bus-errors. The identical program with a LITERAL dimension
(a : [16]T) is correct. Silent-miscompile class (cf. 0079–0082).
Reproduction
#import "modules/std.sx";
N :: 16;
main :: () { a : [N]s64 = ---; a[0] = 7; print("a0={}\n", a[0]); }
./zig-out/bin/sx run prints a0=8472789232 (garbage); want a0=7. Replacing
[N] with [16] prints 7.
Investigation prompt
A fixed-array TYPE whose dimension is a named const (N :: 16; [N]T) resolves to
a wrong element stride / array length in codegen — element address computation is
wrong (garbage for scalars, bad pointer for slice/pointer elements). Literal
dimensions are correct, so the defect is in resolving the array-type DIMENSION
from a constant expression (vs a literal) — the dim likely resolves to 0/unknown
or the element size is wrong. Look at array-type resolution where the length is a
const-expr (type lowering / sizeof / element-stride computation). Fix so a
named-const dimension yields the same layout as the literal. Verify with the
repro (expect 7) + a [N]string/[N]struct case (no bus error, correct reads),
and zig build && zig build test && bash tests/run_examples.sh green.