c98bebc4e3
Completes the issue-0094 fix. attempt-1 made single-assign and address-of diagnose a missing struct field; the stress-review found two remaining defects in that change: 1. lowerMultiAssign's `.field_access` target kept the pre-fix shape — a struct-only loop that defaulted `field_idx 0` / `field_ty .unresolved` on a miss, then built the GEP and stored unconditionally. A missing field (`p.q, y = 2, 3`) silently wrote field 0 (printed `x=2 y=3`, no diagnostic), and a valid promoted-union / tuple member at a non-zero offset corrupted field 0 instead of its own slot. 2. attempt-1's new union branch in lowerExprAsPtr resolved only DIRECT union field names, so `@v.x` on a promoted anonymous-struct member reported "field 'x' not found on type 'Vec2'" even though `v.x = 41` worked. Both lvalue-pointer sites and the multi-assign store now route through one shared resolver, `fieldLvaluePtr`, that handles struct fields, union direct fields, promoted anonymous-struct union members, and tuple elements, and returns null (no field-0 / `.unresolved` default) on a genuine miss. Each caller emits the read path's `emitFieldError` on null. This collapses the three previously-divergent field-lvalue walks into one, fixing the multi-assign missing-field corruption, the promoted-member over-rejection, and (as a side effect of correct resolution) non-zero-offset promoted-union and tuple multi-assign stores. The types.zig tripwire is untouched. Regression tests: - examples/1145 extended: multi-assign missing field (`p.r, y`) errors, exit 1. - examples/0166 (new): promoted union member written and address-of'd, including a non-zero-offset member (`@v.y`), compiles and runs. - src/ir/lower.test.zig: multi-assign missing-field field-not-found unit test.
30 lines
1.2 KiB
Plaintext
30 lines
1.2 KiB
Plaintext
// Assigning to a field that does not exist on a struct produces the same
|
|
// `field 'X' not found on type 'Y'` diagnostic as the read path (1100), and
|
|
// exits 1 — never the `.unresolved` LLVM-emission panic, never a silent store
|
|
// into a neighbouring field.
|
|
//
|
|
// Regression (issue 0094): the lvalue field lookup left `field_ty = .unresolved`
|
|
// (lowerAssignment's assignment-target path) or silently GEP'd field 0 as `.s64`
|
|
// (lowerExprAsPtr's fallback / lowerMultiAssign's struct loop), so a missing-field
|
|
// store either built a pointer-to-`.unresolved` that panicked at LLVM emission or
|
|
// silently wrote field 0. All three lvalue sites now emit the field-not-found
|
|
// diagnostic: the assignment-target path (`p.q`), the nested lvalue-pointer path
|
|
// (`o.missing.a`), and the multi-target store path (`p.r, y`).
|
|
|
|
Point :: struct { x: s64; }
|
|
Inner :: struct { a: s64; }
|
|
Outer :: struct { inner: Inner; }
|
|
|
|
main :: () -> s32 {
|
|
p := Point.{ x = 1 };
|
|
p.q = 2; // site 1: lowerAssignment target path
|
|
|
|
o := Outer.{ inner = Inner.{ a = 1 } };
|
|
o.missing.a = 5; // site 2: lowerExprAsPtr fallback
|
|
|
|
y : s64 = 0;
|
|
p.r, y = 3, 4; // site 3: lowerMultiAssign field path
|
|
|
|
return 0;
|
|
}
|