Skip to content

fix(specs): restore the parsing version of 14 specs master cannot read - #4272

Merged
gHashTag merged 1 commit into
masterfrom
fix/repair-unparseable-specs
Sep 18, 2026
Merged

gHashTag merged 1 commit into
masterfrom
fix/repair-unparseable-specs

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

What is wrong on master

14 spec files on master do not parse. t27c spec-status prints NOPARSE for each, so the compiler cannot generate anything from them and none of the tests they carry ever runs. Measured on ef1951669: 79 of 948 specs are NOPARSE.

Each of these files has a working version: the bee branch that implemented it, whose pull request could not merge because the file had meanwhile been overwritten on master by a version that does not parse. utf8.t27 is the shape of all of them - master's version came from "Implement UTF-8 encoding and decoding functions" (e71afdf) and fails with parse error in fn 'encode' near line 110: unexpected token after expression statement: KwReturn.

Required checks on master are validate and check-linked-issue. Neither runs the compiler over changed specs, so a spec that stops parsing lands without a red check. Corpus Ratchet would have caught it, and it is not required (it is also red for an unrelated reason: #4270).

What this does

Takes the parsing, implemented version of each file from the bee branch that wrote it. Measured with a t27c built from master, before -> after:

master this PR
specs that do not parse 79 65
specs IMPLEMENTED 499 513

Per file, all 14 now print IMPLEMENTED and t27c gen ... | grep -c 'not yet implemented' prints 0:

What it costs, plainly

The versions being replaced carry 58 more test declarations in total. None of them executes today: the file they live in does not parse, so no Zig is generated and zig test never sees them. They are still text somebody wrote, and restoring them on top of a version that parses is follow-up work, not part of this PR.

Four further files were left alone on purpose: trie.t27, quick_sort.t27, csv.t27 and hex.t27. Their unparseable versions declare helper functions the working versions do not have, so replacing them would drop code, not just tests. They keep their NOPARSE status and need a real parse fix.

Closes #3830
Closes #3821
Closes #3798
Closes #3792
Closes #3787
Closes #3785
Closes #3771
Closes #3758
Closes #3747
Closes #3746
Closes #3736
Closes #3735
Closes #3732
Closes #3694

🤖 Generated with Claude Code

79 of 948 specs on master print NOPARSE, so t27c generates nothing from them
and none of the tests they carry runs. Fourteen of them have a working version
sitting in the bee branch that implemented them, whose pull request could not
merge because the file had been overwritten on master by a version that does
not parse (utf8.t27: "parse error in fn 'encode' near line 110: unexpected
token after expression statement: KwReturn", from e71afdf).

Nothing gates this: the required checks are validate and check-linked-issue,
and neither runs the compiler over a changed spec.

Measured with a t27c built from master: NOPARSE 79 -> 65, IMPLEMENTED 499 ->
513, and all 14 files print IMPLEMENTED with zero "not yet implemented" stubs.
The replaced versions hold 58 more test declarations, none of which executes
today, and restoring them over a parsing file is follow-up work. Four files
(trie, quick_sort, csv, hex) were left alone because their broken versions
declare helper functions the working ones do not.

Gates: t27c spec-status over all 948 specs, before and after; per file
`t27c gen <f> > /tmp/g.zig && grep -c 'not yet implemented' /tmp/g.zig` = 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@gHashTag
gHashTag enabled auto-merge (squash) September 18, 2026 14:18
@github-actions

Copy link
Copy Markdown
Contributor

📓 NotebookLM Notebook linked to this PR

This notebook contains session context, decisions, and artifacts for this work.

@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-09-18 14:18:56 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 18
PRs with All Checks Green 32
READY 32
FAILING 18
PENDING 0
NO CHECKS YET 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=403499176a5d != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@gHashTag
gHashTag merged commit a522f88 into master Sep 18, 2026
24 of 33 checks passed
gHashTag added a commit that referenced this pull request Sep 18, 2026
#4272 restored the parsing version of 14 specs and auto-merge landed it on the
two required checks while check-now-freshness and NOW Sync Gate were red: the
entry existed but its push arrived after the merge. The commit is on master;
this is its record - what was measured (NOPARSE 79 -> 65, IMPLEMENTED 499 ->
513), what it cost (58 test declarations that do not execute today), and the
four files left alone because their broken version declares functions the
working one does not.

Closes #4273

Gates: python3 tools/check_now_entry_shape.py --self-check -> ok; no .t27 file
is touched.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
gHashTag added a commit that referenced this pull request Sep 19, 2026
* ci: a spec that parsed must not stop parsing

`t27c spec-status` over the corpus: 68 NOPARSE on 2026-09-14, 68 on 09-16, 90
on 09-17. A spec that does not parse generates nothing, so the tests it carries
stop running; #4272 repaired fourteen of them only by taking back the version
the bee had written.

Nothing caught them. The required checks are validate and check-linked-issue,
and neither runs the compiler over a changed spec.

This gate asks one question over the files a change touches: did a spec that
parsed at the base stop parsing? Already-broken specs are not its business and
a new file cannot regress. A compiler that cannot be run exits 2 - could not
run, not a pass.

Closes #4276

Gates: python3 tools/ci/check_specs_still_parse.py --self-test -> ok (7 shapes);
against the real t27c, a branch that breaks specs/tri/sort/tim_sort.t27 exits 1
naming the parse error, an unrelated change exits 0, a missing compiler exits 2;
python3 scripts/ci/check_pr_branch_filters.py exits 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* ci: classify the new gate, and the nightly I landed without classifying

`check_pr_branch_filters.py` keeps a ceiling on workflows in neither of its
lists, and it moves down only. The population had crept back to 27 because
`oracle-nightly.yml` landed in #4234 unclassified - exactly the slack the
ceiling refuses - and this branch's `spec-parse-ratchet.yml` made 28.

Three are classified here: the parse ratchet and `l1-traceability.yml` as
merge-critical (a branch filter would hide either on a stacked pull request),
`oracle-nightly.yml` as not (it measures the corpus nightly, it does not gate a
merge). Population 25, ceiling follows to 25.

Refs #4276

Gates: python3 scripts/ci/check_pr_branch_filters.py -> exit 0, 23 + 5 + 25 =
53; --self-test -> exit 0 ("one new unclassified workflow fails").

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment