bdd0e96d78
A block's value is now its last statement ONLY when that statement is a trailing expression with no `;`. A trailing `;` discards the value, leaving the block void. This makes value-vs-statement explicit and lets the compiler reject "this block was supposed to produce a value". Compiler: - Parser records `Block.produces_value` (last stmt is a no-`;` trailing expression) + `Block.discarded_semi` (the `;` that discarded a value), via `expectSemicolonAfter`. A trailing expression before `}` may now omit its `;` (previously a parse error). Match-arm and else-arm bodies are built value-producing regardless of the arm `;` (arms are exempt — the `;` is an arm terminator). - Lowering: `lowerBlockValue` / the block-expr path / `inferExprType` respect `produces_value`. A value-position block that discards its value is a hard error (`lowerValueBody` for function bodies; the value-context `.block` path for if/else branches, `catch` bodies, value bindings, match arms). Pure-failable `-> !` bodies (value rides the error channel) and a value-if whose branches are void are handled without false errors. - `defer`/`onfail` cleanup bodies lower as statements (void), so a trailing `;` there is fine. Migration (behavior-preserving — output unchanged): - stdlib + ~210 examples: dropped the trailing `;` on value-position last expressions. `format` now ends with an explicit `#insert "return result;"` (it relied on `#insert`-as-block-value, which `;` discards). - Two `main :: () -> s32` examples that relied on the old silent default-return got an explicit trailing `0`. - Rejection snapshots 0412 / 1013 regenerated (their quoted source lines lost a `;`); the diagnostics themselves are unchanged. Docs/tests: specs.md "Block values" section; examples 0040 (rules) + 0041 (rejection); 3 parser unit tests. Filed issue 0066 (pre-existing match-arm negated-literal phi-width quirk, surfaced not caused here). Gates: zig build, zig build test, run_examples.sh -> 343 passed, cross_compile.sh -> 7 passed (also refreshed its stale example names).
2.4 KiB
0066 — match-as-value with a negated-literal arm builds a mismatched phi
Symptom
A value-position match (the if subject == { case ... } sugar) returning a
small integer type, where one arm is a negated integer literal (-1) and
others are plain positive literals, fails LLVM verification:
LLVM verification failed: PHI node operands are not the same type as the result!
%bp = phi i64 [ 100, %match.arm.1 ], [ 10, %match.arm.2 ], [ -1, %match.arm.3 ]
The negated arm lowers its value at a different integer width (it emits an i32
that is then sign-extended) than the positive-literal arms (i64), so the merge
phi's operands disagree with its result type. Positive literals in every arm
work; if/else with -1 works. So it is specific to a negated literal in a
match arm value.
This is orthogonal to the trailing-; block-value rule — the repro uses the
exempt case …: expr; arm form (unchanged by that migration) and reproduces
with ordinary semicolon-terminated arms. Filed while writing the block-value
regression example (0040); the example sidesteps it with positive arm values.
Reproduction
classify :: (n: s32) -> s32 {
if n == {
case 0: 100;
case 1: 10;
else: -1; // ← negated literal arm → phi width mismatch
}
}
main :: () -> s32 { classify(1) }
Expected: compiles, classify(1) returns 10. Actual: LLVM verification failure.
Workaround: give the arm an explicitly-typed value (else: { x : s32 = -1; x })
or avoid the negation.
Investigation prompt
Look at the match-as-value lowering in src/ir/lower.zig (lowerMatch, the
has_value_merge path ~line 4500, and the arm result_type inference
~line 11698). The arm value is lowered via lowerBlockValue(arm.body) then
coerceToType(v, v_ty, result_type). For a negated-literal arm the value's
type comes out narrower than result_type (s64 here), and the coercion path
that should widen it before the br merge_bb, {v} either runs against the wrong
target or is skipped — so the phi gets an i32 operand under an i64 result. Make
the arm value coerce to the merge's result_type consistently (mirror how the
positive-literal arms are handled), or set target_type = result_type while
lowering each arm body so the negate picks the right width. Verify with the
repro above (expect exit 10) and add a regression example.
Status
OPEN. Pre-existing match-value codegen quirk, surfaced (not caused) by the block-value work.