Repository navigation
t27c: optional capture dropped, orelse unparsed, test-local reassign emitted as const, pointer param var rename #8199
Description
Re-filed from #6358. An attempt claimed that issue on 2026-10-06 and left an empty branch, and a dispatch row that has spent its retry ceiling keeps its issue for good - so no bee could take it again, however much the brief improved. The work below is carried over unchanged.
Found by the t27b optionals lane (#6357), Refs #6063. Each is a t27c (parser or gen-zig) defect that makes the reference path refuse a well-formed spec:
if (x) |v| { ... }-- gen-zig drops the|v|capture; zig then reportsvas undeclared. t27b refuses the shape asStmtIf(capture).orelsedoes not parse in t27c.- In a test block, a plain assignment
w = 9;to a name already declared withvaris emitted asconst w = 9;, a redeclaration zig rejects. - A mutated pointer parameter is renamed to
var p = p_arg;, which zig rejects as "never mutated" when onlyp.*is written.
For 3 and 4, t27b currently passes such files while the reference does not compile them; they sit outside the 720 reference passes, so no count changes, but t27b should refuse them by name until the reference is fixed.
Boundary
bootstrap/src/compiler.rs
User Scenarios
- Given a spec with
if (x) |v| { use(v); }, when compiled by t27c, then the generated Zig must declare the capturevso the Zig compiler accepts it. - Given a spec containing
orelsein an optional chain, when parsed by t27c, then the parser must accept the keyword and produce a valid AST node. - Given a test block where
var w = 1;is followed byw = 9;, when codegen runs, then the reassignment must be emitted as a variable assignment, not aconstredeclaration. - Given a function taking a pointer parameter
p: *i32that mutatesp.*, when codegen renames the parameter, then the generated Zig must not emitvar p = p_arg;if onlyp.*is written.
Requirements
- FR-001: The gen-zig backend MUST emit a capture variable for optional
ifpatterns so the Zig compiler sees the declared name. - FR-002: The parser MUST recognize
orelseas a valid keyword in optional expressions and produce a corresponding AST node. - FR-003: In test blocks, assignments to already-declared
varnames MUST be emitted as mutable assignments, notconstredeclarations. - FR-004: When a pointer parameter is only mutated through dereference (
p.*), the codegen MUST NOT emit avar p = p_arg;shadow that Zig flags as never mutated.
Success Criteria
cargo test -p t27c -- optional_captureexits 0 and the generated Zig forif (x) |v| {}compiles without "undeclared identifier" errors.cargo test -p t27c -- orelse_parseexits 0 and a spec containingorelseparses without syntax errors.cargo test -p t27c -- test_reassign_constexits 0 and the emitted Zig forw = 9;inside a test block compiles without "redeclaration" errors.cargo test -p t27c -- ptr_param_renameexits 0 and the emitted Zig for a mutated pointer parameter compiles without "never mutated" errors.- All 720 reference specs in
specs/tools/tri/test.t27still pass (t27cexit 0).
The instruments
Every one of these reads and prints; none of them writes. Run them from the repository root, with <spec> replaced by the file in ## Boundary:
.t27 is not Rust and not Zig, and a bee fluent in either writes one by
accident. Measured 2026-09-20: a bee filled eight bodies in
specs/file/watcher.t27 with return Ok(());, Err(FileError::WatcherNotFound)
and for i in 0..watchers.length. The parse ratchet refused the whole file --
Unexpected token in expression: RParen, line 123 -- and a spec that does not
parse generates nothing, so every test it already carried stopped running.
At the top level the parser accepts exactly these eight forms, with an optional
pub, and no others:
const var fn enum struct test invariant bench
There is no trait, no impl, no type X = ..., no generics, no macro. What
a bee reaches for from another language, and what happens:
- Rust's result sugar (
Ok(()),Err(E::V),?) is not a construct here. - Rust macros (
println!,format!,vec!) are not constructs here. - A range loop (
for i in 0..n) is Rust and Zig, not this language. - Zig builtins (
catch unreachable,@intCast,@constCast) are not constructs here. - Cross-module reuse (
use other::fn;) parses and then generates a comment and an unqualified call, so the Zig fails withuse of undeclared identifier(use a::b; generates no import, so no spec can reuse a function from another spec #4298). It does not work yet.
t27c parse <spec> answers in one line whether what you wrote is the language.
Run it before you report, every time.
t27c spec-status <spec>- the compiler's one-word verdict: IMPLEMENTED, PARTIAL, UNWRITTEN, NOPARSE, NOFN. Exit code is 0 whatever it says, so read the word.t27c symbols <spec>- every name the file declares, with its kind. Answers "does this already exist here?" before you add it.t27c outline <spec>- per function: its locals, what it calls, what it returns. The contract you are implementing against.t27c coverage <spec>- which functions have a test and which do not. The issue asks for tests; this is how you check you wrote them.t27c lint <spec>- style and shape warnings. It OVER-REPORTShas no test or invariant: measured 2026-09-20 over 60 specs it printed 677 of those wherecoveragefound 190 untested functions, disagreeing on 59 of the 60 - it warns aboutbit_to_trit_pairinspecs/base/ternary_encoding.t27, whichtest bit_to_trit_pair_zerocalls on line 249. Read it as a hint;coverageis the answer.t27c typecheck <spec>- types, before generation. PrintsTypecheck OK (0 errors, 0 warnings)or the errors.t27c test-report <spec>- builds this spec and runs its own tests, which is what the oracle does.BLOCKEDmeans the generated Zig does not compile, with the error beside it.python3 tools/dupe_scan.py --name <function>- where that function already lives, if it does. 576 of 4021 bodies here are byte-identical copies.
The rest of the toolbelt is in docs/BEE_TOOLBELT.md.
Activity