You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
While loops needed optional parens and struct-literal suppression: gate 154 -> 111 events #2588
#2587 found that 138 while loops never reached the output and that unused local variable was their symptom, not a corpus defect. This is the cause and the fix.
Two defects, one construct
Mandatory parentheses.parse_while_stmt began with self.expect(TokenKind::LParen)?. 115 of 586 while statements are written while i < 100 { without them, so the expect failed at the first token and recovery discarded the entire loop.
Struct-literal ambiguity. Making the parens optional was not enough: parse_expr then read while i < count { as count { ... } — a struct literal — and swallowed the loop body, leaving the following return at apparent top level. Rust has the same ambiguity and solves it the same way, with a flag that suppresses struct literals inside an unparenthesised condition.
Zig requires the parentheses, so the emitter writes them regardless of how the spec spelled it: while (i < 100) {.
The gate improvement is the headline: 43 fewer recovery events, the largest single move it has made in 48 iterations of holding at 154.
The two lost specs were passing on deleted code
stdlib_tb.t27 and vcd_trace.t27 were VALID with zero errors. Both had their loops dropped, and the dropped loops took the problematic code with them. Now the loops are emitted and their contents are checked: undeclared identifier 'result' and local variable is never mutated x4.
Same argument as #2584: a file that passes because its broken part was deleted is not passing. Two specs now fail honestly rather than passing on absence.
The intermediate state, recorded because it was tempting
With parens optional but the ambiguity unresolved: 218 valid, 615 errors — far better on both counters than what landed. And the gate FAILED, because 42 specs recovered more than their baseline while the total improved.
That state was the best-looking measurement of the night and it was wrong: the loop bodies were being consumed as struct literals, so the parser was skipping more code, not less. Two counters said yes and the gate said no, and the gate was right.
Closing as done: master's parse_while_stmt (bootstrap/src/compiler.rs:4233-4237, landed in 77926cf and refactored in d21e762#2742) accepts an unparenthesised condition and suppresses struct literals while reading it. Checked with t27c 0.4.0: while i < count { i = i + 1; } parses as StmtWhile with its body and t27c gen emits while (i < count) {; both boundary specs emit their while loops (grep -c 'while (' -> 3 each).
Triage for the review jam, #5776: this card was escalated because it states no acceptance criterion the Queen can read. Reopen if this is wrong.
Activity
gHashTag commentedon Oct 3, 2026
Closing as done: master's parse_while_stmt (bootstrap/src/compiler.rs:4233-4237, landed in 77926cf and refactored in d21e762 #2742) accepts an unparenthesised condition and suppresses struct literals while reading it. Checked with t27c 0.4.0:
while i < count { i = i + 1; }parses as StmtWhile with its body andt27c genemitswhile (i < count) {; both boundary specs emit their while loops (grep -c 'while ('-> 3 each).Triage for the review jam, #5776: this card was escalated because it states no acceptance criterion the Queen can read. Reopen if this is wrong.