Files
sx/issues/0084-slice-literal-direct-call-arg-miscompiled.md
agra d8076b9333 lang: rename signed integer types sN -> iN
Surface rename of the signed integer family: s1..s64 become i1..i64
(u1..u64, usize, isize unchanged). 'string' keeps the s-prefix arm in
name classification; width parsing moves to the i-prefix arm next to
isize.

Internal TypeId tags follow the surface (.s8/.s16/.s32/.s64 ->
.i8/.i16/.i32/.i64), as do mono-key mangle fragments (ptr_i64,
tu_i64_bool) and all display/diagnostic formatting (i{d}).

Migrated in the same sweep: stdlib + examples + issue repros + FFI C
companions (shared symbol names like ffi_id_i64), expected
stdout/stderr/ir snapshots, specs.md, readme.md, CLAUDE.md/AGENTS.md,
implementation_plan.md, docs/, issue writeups. Vendored stb_image and
historical flow state left untouched.

zig build test: 426/426; examples suite: 595/595.
2026-06-12 09:31:53 +03:00

2.5 KiB

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 (coerceCallArgscoerceToTypeCoercionResolver.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 []i64). 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 []i64, 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) -> i64 { 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 []i64 case, gate green.