Files
sx/examples/diagnostics/1196-diagnostics-array-literal-head-unknown-type.sx
agra 28bb101a4a fix: literal element typing — typed-array null element, tuple coercion, positional var element (0173-0175)
0173: resolveArrayLiteralType gained no arm for [N]T/[]T heads, so a
([2]?i64).[...] head lost its ?i64 element type and a bare null reached
LLVM as const_null(.unresolved). Route structural heads through
resolveTypeWithBindings; validate an undefined element name in the head
via UnknownTypeChecker (semantic_diagnostics.zig) instead of a silent
empty-struct stub (no-silent-fallback).

0174: positional .{...} against a TUPLE target now coerces each element
to TupleInfo.fields[i] (was neither struct nor array, so uncoerced).

0175: a positional struct literal with a bare-variable element was
misclassified as a named shorthand (parser puns .{x} -> x=x), zeroing
the fields. has_names now consults the struct definition to reclassify a
punned non-field name as positional; positional coercion uses the
lowered value's real getRefType.

Regressions: optionals/0914, types/0199, types/0200, diagnostics/1196.
Verified by 4 adversarial reviews; suite 784/0. Filed adjacent bug 0176
(protocol-typed struct field method call aborts).
2026-06-23 00:25:28 +03:00

22 lines
1.1 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
// A typed array/slice literal head (`([N]T).[…]` / `([]T).[…]`) names its
// element type exactly like a declaration annotation, so an UNDEFINED element
// type name must be rejected with the same `unknown type '<name>'` diagnostic
// the declaration path emits — NOT silently compiled.
//
// Regression (issues 01730175 adversarial review): the 0173 fix taught the
// lowering's `resolveArrayLiteralType` to resolve a structural `[N]?T` head,
// but for an UNDEFINED element name the resolver returned a forward-reference
// empty-struct STUB instead of `.unresolved`. So `([2]?Undefined).[…]`
// compiled silently (exit 0, "ok") with a wrong empty-struct element, where
// `x: [2]?Undefined = ---` correctly errored. The unknown-type checker
// (`semantic_diagnostics.zig` `walkBodyTypes`) now validates the array
// literal's `type_expr` head through the same `checkTypeNodeForUnknown` walk a
// declaration uses, so a genuinely-undeclared head element name is a loud,
// located error (exit 1) — never a silent empty-struct compile or a raw panic.
#import "modules/std.sx";
main :: () {
arr := ([2]?Undefined).[ null, null ];
print("ok\n");
}