8b613af96b
The type-erased value type is spelled Any (capital), per specs.md and type_resolver.zig. Lowercase 'any' is an undefined name that resolves to an empty-struct stub, which is why ?any appeared to silently discard the value. ?Any round-trips correctly (present/absent/unwrap all work), so there is no Any-TypeId canonicalization bug. Reword the 0165 cross-ref accordingly.
3.3 KiB
0165 — parenthesized nested optional ?(?T) resolves to a malformed double-wrapped type
RESOLVED. The issue's premise was partly wrong: per
specs.md:843, in TYPE position(T)is a single-field TUPLE, not a grouping — so?(?i64)isoptional(tuple(?i64))and the compiler's{ {{i64,i1}}, i1 }layout was CORRECT. The real bug was a silent malformed-IR path: assigning a bare?i64to it hadcoerceToTypeclassify.noneand pass the value through unchanged, thenoptionalWrapbuilt a corruptinsertvaluethat aborted the LLVM verifier. Fix: after coercing toward an optional's child, verify the coerced value's type equals the child type (src/ir/lower/stmt.zigdecl-init +src/ir/lower/coerce.zig.optional_wrap); on mismatch emit a located diagnostic (with a tuple-specific note only when the child is a tuple) instead of corrupt IR.formatTypeNamenow renders tuples as(x: i64, y: i64). Genuine nested optionals via alias (Opt :: ?i64; ?Opt) work and round-trip. Regressions:examples/optionals/0911-nested-optional-via-alias.sx,examples/diagnostics/1195-diagnostics-err-parenthesized-optional-tuple.sx. Verified by 3 adversarial reviews. (A review noted?anyover-rejection; that turned out to be a casing non-bug — lowercaseanyis an undefined name, the type isAny; see 0171, closed NOT-A-BUG.)
Symptom
A nested optional written ?(?i64) resolves to a spurious extra struct wrapper:
the destination type lowers to { { {i64,i1} }, i1 } (triple-wrapped) instead of
the correct { {i64,i1}, i1 }. Assigning an inner ?i64 then fails the LLVM
verifier:
LLVM verification failed: Invalid InsertValueInst operands!
%ow.val = insertvalue { { { i64, i1 } }, i1 } undef, { i64, i1 } %load, 0
Crash (non-zero exit). ??i64 (unparenthesized) is a separate parse error
(expected type name) and is NOT this bug — only the parenthesized ?(?T) form
reaches type resolution and produces the malformed layout.
Reproduction
#import "modules/std.sx";
main :: () {
inner : ?i64 = 5;
outer : ?(?i64) = inner;
print("ok\n");
}
Expected: ok (a well-formed { {i64,i1}, i1 } outer optional wrapping the
inner ?i64). Observed: LLVM verifier abort.
Investigation prompt
The type-table interning (src/ir/types.zig optionalOf / the optional
lowering near types.zig:87) produces the CORRECT { {i64,i1}, i1 } for a
real optional(optional(i64)). So the malformed layout comes from
instruction.ty itself: the parenthesized (?i64) inner type expression is
resolved as a single-field STRUCT wrapping ?i64, not as the optional type
directly. Suspected area: resolution of a parenthesized type expression
(src/ir/type_resolver.zig and/or the parser's handling of (?T) as a type) —
a parenthesized type should resolve to the inner type unchanged, not introduce a
tuple/struct wrapper. src/backend/llvm/ops.zig emitOptionalWrap is the
faithful victim (it uses toLLVMType(instruction.ty)), not the cause.
Verify: the repro prints ok; ?(?i64) round-trips (unwrap inner, read value);
confirm the IR type is { {i64,i1}, i1 }. Add an
examples/optionals/09xx-nested-parenthesized-optional.sx regression. (The
unresolved type panic seen when an ! unwrap is added is downstream recovery
fallout of the same root cause — should disappear once the layout is correct.)