Repository navigation
t27c gen-zig drops needed parentheses: (if ..) + 1 and -(x - y) #6329
Description
Found by the t27b ExprIf lane (#6328, Refs #6063).
t27c gen-zig prints compound expressions without the parentheses the source needs, so the generated Zig means something else:
(if (c) a else b) + 1is emitted asif (c) a else b + 1. Zig parses the+ 1into the else arm. The same holds for(if ...).xand(if ...)[i]. A probe passes under t27b, which keeps the source meaning, and fails under the reference path.-(x - y)is emitted as-x - y.
Effect on t27b: it refuses shape 1 as ExprIf(left operand) because no correct lowering can match the reference. Shape 2 will show up as a mismatch on any test that reaches it.
Fix direction: the gen-zig expression printer should parenthesize a child whose precedence is lower than its parent's (an if-expression is always lowest), and should always parenthesize the operand of unary minus when it is a binary expression.
Boundary
bootstrap/src/compiler.rs
User Scenarios
- Given a T27 source expression
(if (c) a else b) + 1, when compiled witht27c gen-zig, then the emitted Zig code must preserve the addition outside the if-expression, not fold it into the else arm. - Given a T27 source expression
-(x - y), when compiled witht27c gen-zig, then the emitted Zig code must preserve the unary minus applied to the entire subtraction, not rewrite it as-x - y.
Requirements
- FR-001: The gen-zig expression printer MUST parenthesize any child expression whose precedence is lower than its parent operator's precedence.
- FR-002: The gen-zig expression printer MUST always parenthesize the operand of a unary minus when that operand is a binary expression.
- FR-003: The gen-zig expression printer MUST treat if-expressions as having the lowest precedence, requiring parentheses when used as operands to any other operator.
Success Criteria
t27c gen-zigon a fixture containing(if (c) a else b) + 1emits Zig code that parses as(if (c) a else b) + 1(verified by Zig parser or round-trip test), exit 0t27c gen-zigon a fixture containing-(x - y)emits Zig code that parses as-(x - y)(verified by Zig parser or round-trip test), exit 0- The t27b ExprIf lane probe for shape 1 passes against the reference path, 1 test
- The t27b mismatch for shape 2 is resolved on reaching tests, 1 test
bootstrap/src/compiler.rscompiles without errors, exit 0
Activity
gHashTag commentedon Oct 5, 2026
Two more gen-zig printing defects seen by the t27b char-literal lane (#6331):
const X: u8 = 'a';loses its value; gen printsconst X: u8;(t27b refuses it asConstDecl ... has no value)..'a' =>, which Zig rejects.gHashTag commentedon Oct 5, 2026
Also from the t27b [N]T lane (#6347): t27c does not parse a module-level
const X: [u32; N] = [0; N];(repeat-literal initializer);[_]u32{0} ** Nworks.gHashTag commentedon Oct 5, 2026
From the t27b switch lane (#6353): t27c inlines a typed local
const w: u16 = 1000;as the bare literal1000, so zig peer-types an if/switch with a u8 arm to u8 and refuses the value; the reference is BLOCKED where the source is well typed.gHashTag commentedon Oct 5, 2026
Dogfood (#6457): specs/compiler/rust_repeat_counts.t27 is BLOCKED because a repeat count loses its parentheses: gen emits
return .{ value } ** COUNT32*2-1;("incompatible types: struct { u32, u32, u32, u32 } and comptime_int", lab run 682564f).