spec: legalize five wave-era specs for cross-backend validity - #321
Merged
Conversation
Five more Rust-isms / latent bugs in wave-era specs, surfaced by the Zig validity sweep and real in every backend: m3_multihop used the Rust method call 0x100_u8.wrapping_sub(x) (parser silently mangled it -- the function lost its return) and an 0x100_u16 suffixed literal; bandwidth_allocator's tests referenced PRIORITY_LOW/MEDIUM/HIGH that were never declared (its generated code could not compile anywhere); production_scenarios' accessor fn node_state was shadowed by four params of the same name (renamed the accessor to node_state_of); integration_framework and test_validator used 'error' -- a Zig keyword -- as a parameter name (renamed to err_word). Rust gens for the five regenerated; drift check green on all; full local gate green (77 test targets). gen/ changes are t27c regenerations (L2 bypassed per the guard's fix path). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Aug 8, 2026
…st-check clean (#322) The gen-zig validity campaign (t27#1910, closed by #1911/#1915/#1917/#1918 plus tri-net's spec legalizations #310/#321) took the backend from 66/68 invalid to 0/68. gen/zig/ returns with all 68 files (each validated with zig ast-check 0.15.2), and spec-drift-guard's Zig leg is back: byte-exact diff against 't27c gen' built from upstream master (no formatter in the Zig path, so no fmt-vs-drift contradiction). Two backends now under the required drift gate. gen/ additions are t27c generations (L2 bypassed per the guard's fix path). Co-authored-by: SSD DDD <ssdm4@MacBook-Pro.local> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
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.
The Zig validity sweep surfaced five more latent spec bugs, real in every backend: m3_multihop used Rust method-call syntax
0x100_u8.wrapping_sub(x)(the t27 parser silently mangled it -- the function lost its return) plus a suffixed0x100_u16literal; bandwidth_allocator's tests referenced PRIORITY_LOW/MEDIUM/HIGH constants that were NEVER DECLARED (its generated code could not compile in any backend and nothing noticed); production_scenarios' accessornode_statewas shadowed by four same-named params (accessor renamed tonode_state_of); integration_framework and test_validator usederror-- a Zig keyword -- as a parameter name.Rust gens for the five regenerated (drift check green), full local gate green. Together with the t27-side Zig fixes (var-inference,
_destructuring,_ = &xsilencer), zig ast-check validity reaches 65/68 -- only the three deferred long-tails (array-literal parse path x2, CSE decl-ordering) remain, tracked upstream.🤖 Generated with Claude Code