sx/issues/0094-missing-struct-field-assignment-unresolved-panic.md

0094 — assigning to a missing struct field panics with "unresolved type reached LLVM emission"

RESOLVED (F0.10). Root cause: the lvalue field lookup never diagnosed a missing field. In Lowering.lowerAssignment's .field_access target path (src/ir/lower.zig), field_ty started as .unresolved; when no struct field matched, the code still built ptrTo(field_ty) / structGepTyped and stored — so a pointer-to-.unresolved reached LLVM emission and tripped the src/backend/llvm/types.zig tripwire. The nested lvalue-pointer path (Lowering.lowerExprAsPtr's .field_access fallback) had the sibling defect: on a miss it returned structGepTyped(obj_ptr, 0, .i64, obj_ty) — a silent field-0/.i64 default.

Fix (src/ir/lower.zig): all three lvalue field-store sites — single assignment, address-of, and multi-target assignment — route field resolution through one shared helper, fieldLvaluePtr(obj_ptr, obj_ty, field), which resolves struct fields, union/tagged-union direct fields, promoted anonymous-struct union members, tuple elements, and vector lanes (reusing vectorLaneIndex), and returns null (no field 0 / .unresolved /.i64 default) when nothing matches. Each caller emits the read path's field-not-found diagnostic (emitFieldError) on a null result:

1. lowerAssignment .field_access target — delegates to fieldLvaluePtr; its own duplicated union / promoted / tuple / vector / struct walk is deleted (issue-0083 two-resolver divergence removed).
2. lowerExprAsPtr .field_access — delegates to fieldLvaluePtr, so the address-of path resolves promoted union members (@v.x) — not only direct union fields — and a genuine miss errors. The .i64 sentinel is gone.
3. lowerMultiAssign .field_access target — replaced its struct-only loop (which defaulted field_idx 0 / field_ty .unresolved on a miss, silently storing into field 0 — p.q, y = 2, 3 printed x=2 y=3) with the shared fieldLvaluePtr; a missing field now errors, and a valid promoted-union / tuple member at a non-zero offset stores into its own slot, not field 0.

fieldLvaluePtr types every GEP *field_ty (a pointer to the field), the convention the single-assign path always used: emitStore reads the store-target pointer's IR type and unwraps exactly one .pointer level to find the stored value's type. The earlier lowerExprAsPtr / lowerMultiAssign walks typed the GEP with the bare field value type, so a field whose own type is a pointer-to-aggregate (*Pair, a two-pointer struct) made emitStore unwrap to the aggregate and coerceArg's closure auto-promotion store a 16-byte {ptr,null} struct over the 8-byte slot — clobbering the neighbouring field. Consolidating all three sites onto the one *field_ty resolver preserves single-assign and fixes that pre-existing multi-assign / address-of clobber.

All sites reuse emitFieldError (the exact facility the read path lowerFieldAccessOnType uses), so the read and write paths reject identically. The src/backend/llvm/types.zig tripwire is untouched — the fix is to never produce .unresolved for a missing-field store.

Regression tests: examples/1145-diagnostics-missing-struct-field-assign.sx (negative — single-assign, address-of, AND multi-assign missing-field all error, exit 1), examples/0165-types-nested-struct-field-assign.sx (positive — nested struct field write + address-of a matched field), examples/0166-types-union-promoted-member-lvalue.sx (positive — promoted union member written and address-of'd, including a non-zero offset member), examples/0167-types-ptr-to-aggregate-field-store.sx (positive — a *Pair field stored via all three lvalue sites leaves the neighbour intact), and three lowering unit tests in src/ir/lower.test.zig (single- and multi-assign missing-field field-not-found, plus the *field_ty GEP convention).

Symptom

Assigning to a nonexistent struct field (p.q = ...) panics during LLVM emission instead of reporting a source diagnostic.

Observed: the compiler reaches the .unresolved LLVM tripwire in src/backend/llvm/types.zig:175 via emitStore. Expected: a normal compile error like field 'q' not found on type 'Point', matching the read-field diagnostic path.

Reproduction

Point :: struct { x: i64; }

main :: () {
    p := Point.{ x = 1 };
    p.q = 2;
}

Running ./zig-out/bin/sx run repro.sx currently panics with:

panic: unresolved type reached LLVM emission — a type resolution failure was not diagnosed/aborted

Investigation prompt

Fix issue 0094 in the sx compiler: assigning to a missing struct field (p.q = 2) panics with .unresolved reaching LLVM emission instead of emitting a field-not-found diagnostic.

Suspected area: src/ir/lower.zig, especially Lowering.lowerAssignment's .field_access target path around the struct-field lookup (field_ty starts as .unresolved, no matched field diagnoses, then ptrTo(field_ty) is stored) and the related Lowering.lowerExprAsPtr field-access fallback that returns structGepTyped(obj_ptr, 0, .i64, obj_ty) on lookup failure. The fix should make failed lvalue field lookup loud, reusing emitFieldError(obj_ty, field, span) or equivalent, and should not use .i64, .void, or any real type as a sentinel.

Verification: run the repro and expect exit 1 with a source diagnostic field 'q' not found on type 'Point'; no LLVM panic. Then run zig build, zig build test, and bash tests/run_examples.sh.