lab/sx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(ir): resolve named-const array dims (0083) + materialize literal slice args (0084)

Browse Source 
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.
This commit is contained in:
agra
2026-06-04 08:22:45 +03:00
parent 3b36264e65
commit 12552e125d
15 changed files with 251 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
issues/0083-named-const-array-dimension-miscompiled.md Normal file
View File

@@ -0,0 +1,42 @@
# 0083 — fixed array with a named-constant dimension is miscompiled
> **RESOLVED.** Root cause: `TypeResolver.resolveCompound`'s array arm resolved
> the dimension with `if (length.data == .int_literal) ... else 0` — a named
> const (`N :: 16`) hit the silent `else 0`, so `[N]T` became 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
> to `inner.resolveArrayLen` (symmetric with `inner.resolveInner` for the element
> type). The stateful `Lowering.resolveArrayLen` evaluates 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
```sx
#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.

43
issues/0084-slice-literal-direct-call-arg-miscompiled.md Normal file
View File

@@ -0,0 +1,43 @@
# 0084 — array/slice literal passed directly as a call argument miscompiles
> **RESOLVED.** Root cause: `lowerArrayLiteral` always produces an aggregate
> ARRAY value; the array→slice conversion is the caller's job. The local-bound
> var-decl path did it (emits `array_to_slice`), but the call-argument coercion
> path (`coerceCallArgs` → `coerceToType` → `CoercionResolver.classify`) had no
> array→slice arm, so `classify([N]T, []T)` returned `.none` and 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:
> `classify` now returns a new `.array_to_slice` plan for `[N]T → []T` (same
> element type), and `coerceToType` emits the existing `array_to_slice` op, 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
```sx
#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.