From 57979ed8e69244d5260c549bfe2e35ff468d2ae7 Mon Sep 17 00:00:00 2001
From: agra <alex@swipelab.co>
Date: Thu, 11 Jun 2026 12:02:03 +0300
Subject: [PATCH] =?UTF-8?q?issues:=20file=200117=20=E2=80=94=20indexing=20?=
 =?UTF-8?q?through=20*[N]T=20panics=20at=20LLVM=20emission?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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.
---
 ...pointer-to-array-index-unresolved-panic.md | 52 +++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 issues/0117-pointer-to-array-index-unresolved-panic.md

diff --git a/issues/0117-pointer-to-array-index-unresolved-panic.md b/issues/0117-pointer-to-array-index-unresolved-panic.md
new file mode 100644
index 0000000..6b391a7
--- /dev/null
+++ b/issues/0117-pointer-to-array-index-unresolved-panic.md
@@ -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.