One missing brace in 27 specs — the cross-target proof was never running - #2186
Merged
Conversation
…f was never running
emit-bitexact has been red since 2026-08-14. The cause is one character.
A bulk edit appended 'test <name>_w339_batch_depth_invariant_2 {' to 27 spec
files and omitted the closing brace in every one, so the parser hits the next
'test' keyword while still inside the block. Three layers then reported three
different things, and only the innermost was true:
CI gate IGLA RACE CROSS-TARGET MISMATCH nothing was compared
verify_igla_race.py FAIL: C backend failed to build the backend never ran
t27c parse error in fn '...' near line 1815: unexpected token
after expression statement: KwTest <- correct
verify_igla_race.py runs its builds with capture_output=True and inspects only
returncode, so the compiler's message -- which named the file, the function, the
line and the token -- was collected and discarded. A diagnostic that names the
wrong subsystem costs more than no diagnostic: 'the C and Rust backends diverge'
is a much more alarming claim than 'a spec has a typo', and it is where four days
of reading went.
There was no cross-target divergence. With the braces closed:
OK ternary_mul/mac: C == reference BIT-EXACT over 800 vectors
OK ternary_mul/mac: Rust == reference BIT-EXACT over 800 vectors
OK systolic_ternary_pe: C == reference BIT-EXACT over 800 vectors (i16 psum)
OK systolic_ternary_pe: Rust == reference BIT-EXACT over 800 vectors (i16 psum)
#2184 is corrected accordingly. The i16 + i8 no-cast gap in gen_rust is real and
documented in the script, but it is worked around there and was never the cause.
The 27 sites were edited mechanically only after confirming all 27 share one
shape -- comment, assert(true), blank line -- and the one already-correct site
was left alone. Each file's parse was then checked individually.
tools/check_specs_parse.py asks what the three layers did not, prints the
compiler's own message, and carries a negative control that plants an unclosed
block and proves the gate rejects it. It runs ahead of every other step because
it is their precondition.
Reported, not fixed: closing the braces reveals 15 of 27 igla specs still failing
on unrelated parser features (unknown cast target type f32, Unexpected top-level
token KwModule), overlapping #2174.
Closes #2185
Refs #2184
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
emit-bitexacthas been red since 2026-08-14 (#2184). The cause is one character.A bulk edit appended
test <name>_w339_batch_depth_invariant_2 {to 27 spec files and omitted the closing}in every one. The parser then hits the nexttestkeyword while still inside the block:That message is exact — file, function, line, token. Nothing surfaced it, because three layers each reported something else:
IGLA RACE CROSS-TARGET MISMATCHverify_igla_race.pyFAIL: C backend failed to build/runt27cparse error … near line 1815verify_igla_race.pyruns its builds withcapture_output=Trueand inspects onlyreturncode, so the compiler's message was collected and discarded. A diagnostic that names the wrong subsystem costs more than none: it sends the reader to the backend, and the top-level claim ("the C and Rust backends diverge") is far more alarming than the truth.After closing 27 braces,
verify_igla_race.pyexits 0:So there was no cross-target divergence. #2184 is corrected by this: the
i16 + i8no-cast gap ingen_rustis real and separately documented in the script, but it is worked around there and was never what made the gate red.Not in scope, deliberately. Closing the braces reveals that 15 of 27 igla specs still fail on unrelated parser features (
unknown cast target type f32,Unexpected top-level token: KwModule), overlapping #2174. Those are a different class and are reported, not fixed here.Gate:
tools/check_specs_parse.pyasks the question those three layers did not — doest27caccept the file — and prints the compiler's own message. It carries a negative control that plants an unclosed block and proves the gate rejects it.Refs #2184
Closes #2185
🤖 Generated with Claude Code