issues: file 0117 — indexing through *[N]T panics at LLVM emission

Pre-existing (plain locals repro it); found pinning @K reads for
PLAN-CONST-AGG step 1, which is now blocked on it. No deref spelling
works: p[2] hits the unresolved-type tripwire, (*p)[2] doesn't parse.
This commit is contained in:
agra
2026-06-11 12:02:03 +03:00
parent a2bd5b0438
commit 57979ed8e6

View File

@@ -0,0 +1,52 @@
# 0117 — indexing through a pointer-to-array panics at LLVM emission
**Symptom.** Indexing through a `*[N]T` pointer is neither lowered nor
diagnosed: the index expression reaches the LLVM emitter with the
`.unresolved` type sentinel and trips the panic tripwire.
- **Observed**: `panic: unresolved type reached LLVM emission`
(src/backend/llvm/types.zig:175, via `emitIndexGet`).
- **Expected**: either `p[2]` auto-derefs the pointer-to-array (load the
pointer, GEP into the array — mirroring the field-access auto-deref on
struct pointers), or a clean diagnostic if indexing through `*[N]T` is
out of spec. Never an emit-time panic.
Pre-existing — reproduces on plain locals with no module-level features
involved (found while pinning `@K` reads for PLAN-CONST-AGG step 1; the
same panic fires for `@<var-decl global array>` and `@<array const>`).
Also note: the explicit-deref spelling `(*p)[2]` does not parse as a
deref — it lowers as `unknown_expr` ("unresolved 'unknown_expr'"), so
there is no working spelling for reading an element through a
pointer-to-array.
## Reproduction
```sx
#import "modules/std.sx";
main :: () {
k : [4]s64 = .[11, 22, 33, 44];
p := @k; // *[4]s64
print("{}\n", p[2]); // expected 33; panics at emission today
}
```
## Investigation prompt
`emitIndexGet` receives an `index_get` whose result type is `.unresolved`
— the lowering of `index_expr` over a receiver of pointer-to-array type
produces no deref. Suspected area: the index lowering in
src/ir/lower/expr.zig (`lowerIndexExpr` or equivalent — find the
`index_expr` arm) and its typing twin in src/ir/expr_typer.zig: both
handle array / slice / many-pointer receivers but not
`pointer → array`. The fix likely mirrors the struct-pointer auto-deref:
when the receiver type is `.pointer` whose pointee is `.array`, load the
pointer value and index the pointee array (element type = pointee
element), in BOTH the typer and the lowering. Check the assignment-target
path too (`p[1] = v` through a pointer-to-array).
Verification: the repro above prints `33`; add a pin under
examples/01xx-types-… covering read AND write-through
(`p[1] = 5; print k[1]` → 5 for a mutable local). Suite + zig build test
stay green.