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.5 KiB
0084 — array/slice literal passed directly as a call argument miscompiles
RESOLVED. Root cause:
lowerArrayLiteralalways produces an aggregate ARRAY value; the array→slice conversion is the caller's job. The local-bound var-decl path did it (emitsarray_to_slice), but the call-argument coercion path (coerceCallArgs→coerceToType→CoercionResolver.classify) had no array→slice arm, soclassify([N]T, []T)returned.noneand the raw array value was passed where a slice was expected — the callee read its {ptr,len} header off the wrong bytes (returned 0 / garbage, segfaulted for[]s64). Fix:classifynow returns a new.array_to_sliceplan for[N]T → []T(same element type), andcoerceToTypeemits the existingarray_to_sliceop, which materializes the array into addressable storage and builds the slice header — identical to the local-bound path. Files:src/ir/conversions.zig,src/ir/lower.zig. Regression:examples/0141-types-slice-literal-direct-call-arg.sx(string + numeric[]s64, direct vs local-bound).
Symptom
A .[...] array/slice literal passed DIRECTLY as a call argument yields a slice
whose element CONTENTS are not reliably readable in the callee (silent — reads
garbage, wrong results). Binding the same literal to a typed local first and
passing the local is correct.
Reproduction
#import "modules/std.sx";
show :: (xs: []string) -> s64 { n:=0; i:=0; while i<xs.len { if xs[i]=="nope" {n+=1;} i+=1; } return n; }
main :: () {
print("direct={}\n", show(.["a","nope","b","nope"])); // prints 0 (WRONG)
local : []string = .["a","nope","b","nope"]; print("local={}\n", show(local)); // prints 2 (correct)
}
Want both 2. Direct-literal-arg returns 0.
Investigation prompt
Passing a .[...] literal directly as a call arg builds a slice/array temporary
whose backing storage is not correctly materialized/kept alive for the callee —
the slice header may point at a stack temp that is clobbered, or the elements are
not stored before the call. Binding to a typed local first works (the local's
storage backs the slice). Look at how a literal aggregate argument is lowered at a
call site (materialize the literal into addressable storage whose lifetime spans
the call, then pass a slice/pointer to it) vs the local-bound path. Fix so a
directly-passed literal arg behaves identically to a local-bound one. Verify with
the repro (both 2) + a numeric []s64 case, gate green.