Files
sx/issues/0085-nested-slice-literal-elements-not-coerced.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.6 KiB

0085 — nested slice literal elements are stored as raw arrays

RESOLVED. Root cause: Lowering.lowerArrayLiteral lowered each element with the element type as target_type but appended the returned value directly. For a nested .[...] element whose expected element type is a slice ([]T), the inner literal still lowers to an aggregate ARRAY [N]T — so the outer aggregate (typed array-of-[]T) held raw arrays where slice {ptr,len} headers were expected; indexing the inner slice read a garbage pointer and segfaulted. Fix: after lowering each element, when the element type is a slice and the lowered value is a same-element array, coerce it via the existing array_to_slice op (materialize backing storage + build the header) — identical to the whole- literal coercion the var-decl / call-arg paths already run. The coercion recurses with the nesting, so [][]T and deeper materialize at every level. Files: src/ir/lower.zig (lowerArrayLiteral). Regression: examples/0142-types-nested-slice-literal-elements.sx ([][]i64 + [][]string, local-bound AND direct-call-argument forms).

Symptom

Nested array/slice literals such as .[.[1, 2], .[3, 4]] miscompile when the expected element type is a slice ([][]i64). Observed: both the local-bound and direct-call forms segfault while indexing the inner slice. Expected: both forms materialize each inner [N]T literal as a []T slice and print the same value.

Reproduction

#import "modules/std.sx";

sum_nested :: (xss: [][]i64) -> i64 {
    return xss[0][1] + xss[1][0];
}

main :: () {
    local : [][]i64 = .[.[1, 2], .[3, 4]];
    print("local={}\n", sum_nested(local));
    print("direct={}\n", sum_nested(.[.[1, 2], .[3, 4]]));
}

Observed on flow/sx-foundation/F0.4: segfault at address 0x9 before either line prints. Expected output:

local=5
direct=5

Investigation prompt

Fix nested slice literal materialization. The likely area is src/ir/lower.zig in Lowering.lowerArrayLiteral: the outer literal can know its expected element type is []T, and the loop sets self.target_type = elem_ty while lowering each inner literal, but it appends the returned value directly. For an inner .[...], that returned value is still an array aggregate [N]T, not the target []T slice. Add per-element coercion/materialization after lowering each element, using the element source type and expected elem_ty (the existing array_to_slice coercion should be reused). Verify the repro prints local=5 and direct=5, then run zig build && zig build test && bash tests/run_examples.sh.