d8076b9333
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.
56 lines
2.6 KiB
Markdown
56 lines
2.6 KiB
Markdown
# 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
|
|
```sx
|
|
#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:
|
|
```text
|
|
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`.
|