lab/sx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: diagnose ?(?T) tuple-payload mismatch instead of malformed IR (issue 0165)

Browse Source 
In type position (T) is a 1-tuple (specs.md:843), so ?(?i64) is
optional(tuple(?i64)); assigning a bare ?i64 had coerceToType classify
.none and pass the value through, then optionalWrap built a corrupt
insertvalue that aborted the LLVM verifier. After coercing toward an
optional's child, verify the coerced type equals the child type
(stmt.zig decl-init + coerce.zig .optional_wrap); on mismatch emit a
located diagnostic (tuple-specific note only when the child is a tuple).
formatTypeName now renders tuples as (x: i64, y: i64).

Regressions: optionals/0911 (nested optional via alias, round-trip),
diagnostics/1195 (the mismatch diagnostic). Updated diagnostics/1101 +
protocols/0414 goldens for the improved tuple type-name rendering.
Verified by 3 adversarial reviews. Filed adjacent bug 0171 (?any child
not canonicalized).
This commit is contained in:
agra
2026-06-22 21:54:12 +03:00
parent 3e8d003e3d
commit 0bc8005b99
16 changed files with 198 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
examples/diagnostics/expected/1195-diagnostics-err-parenthesized-optional-tuple.stderr Normal file
View File

@@ -0,0 +1,5 @@
error: cannot assign a value of type '?i64' to optional '?(?i64)': its payload type is '(?i64)' (note: in type position '(T)' is a single-field tuple, not a grouping — write the inner optional without parentheses)
--> examples/diagnostics/1195-diagnostics-err-parenthesized-optional-tuple.sx:16:3
|
16 | outer : ?(?i64) = inner;
| ^^^^^^^^^^^^^^^^^^^^^^^^