Skip to content

tri abandoned: recoveries whose comment names what they discard - #2781

Merged
gHashTag merged 1 commit into
masterfrom
w699-abandoned
Aug 29, 2026
Merged

tri abandoned: recoveries whose comment names what they discard#2781
gHashTag merged 1 commit into
masterfrom
w699-abandoned

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

Refs #2754

Four defects closed on the W699 line were shapes the parser had already described in prose and never handled:

// BDD-style fn: `fn name() given ... then ...` -- a keyword-style test
// spelled as a fn (linker.t27). Detect BEFORE return-type parsing.
if ... lexeme == "given" {
    self.skip_to_next_top_level();   // every clause, gone

Somebody understood the shape well enough to write it down, name the file it affects, and stop one line short of lowering it. This finds that pattern.

Validated against the past — the only control that means anything

Run at master it names one site. That result is consistent with works perfectly and with matches nothing, so it proves neither.

Run against a520590ef, the commit before any of the four fixes:

names: `fn name() given ... then ...`      <- the rung-5 defect, verbatim
names: `invariant name: <expr>`            <- the arm that discards forall
names: `given p = 0;`
names: `FPGA_PART_35T and p100`
4 of 19 recovery site(s) name a construct in their comment

Two of four, and the window stays where it is

The same control says it would have found two of the four. The comments for comma-separated bindings and for typed bindings sit at the top of the clause loop, hundreds of lines from the recovery they describe.

Widening the search until the count reaches four would be fitting the instrument to its own motivating examples — after which it measures nothing, because any window large enough to catch those attributes unrelated comments to unrelated sites. The miss rate is in the module docs and the window is unchanged.

Precision

The first version matched any backticked phrase containing a space or punctuation. It fired on children.is_empty() and gibberish foo — a Rust expression and a doc-comment fixture — and buried the one real hit.

Requiring a t27 keyword as a whole word inside the quote:

hits at master hits on the control
backticks only 5 (1 real) 9
+ t27 keyword 1 (1 real) 4

Backticks say somebody quoted something; the keyword says what they quoted.

It reports and never fails

A comment beside a recovery is not a defect — the forall arm is exactly this shape and is correct pending #2774. A gate that fails on a judgement call gets muted, and a muted gate is worse than a list nobody is forced to read.

The one live hit is a lead rather than a false positive: parse_expr over-consuming across a newline (FPGA_PART_35T and p100), 8 fallback events across 3 specs.

Four tests, two of them for what it must not match.

🤖 Generated with Claude Code

…t they discard

Four defects closed on the W699 line were shapes the parser had already described
in prose and never handled. Each looked like this:

    // BDD-style fn: `fn name() given ... then ...` -- a keyword-style test
    // spelled as a fn (linker.t27). Detect BEFORE return-type parsing.
    if ... lexeme == "given" {
        self.skip_to_next_top_level();   // every clause, gone

Somebody understood the shape well enough to write it down, name the file it
affects, and stop one line short of lowering it. This finds that pattern.

VALIDATED AGAINST THE PAST, WHICH IS THE ONLY CONTROL THAT MEANS ANYTHING. Run at
master it names ONE site -- consistent with "works" and with "matches nothing".
Run against a520590, the commit before any of the four fixes, it names four,
among them `fn name() given ... then ...` verbatim and the `invariant name:` arm
that discards `forall`.

TWO OF FOUR, and the window stays where it is. The comments for comma-separated
bindings and for typed bindings sit at the TOP OF THE CLAUSE LOOP, hundreds of
lines from the recovery they describe. Widening the search until the count
reaches four would be fitting the instrument to its own motivating examples,
after which it measures nothing. The miss rate is in the module docs.

PRECISION. The first version matched any backticked phrase with a space or
punctuation and fired on `children.is_empty()` and `gibberish foo` -- a Rust
expression and a doc-comment fixture -- burying the one real hit. Requiring a t27
keyword as a whole word inside the quote took it from 5 hits (1 real) to 1, and
from 9 to 4 on the historical control. Backticks say somebody quoted something;
the keyword says what.

IT REPORTS AND NEVER FAILS. A comment beside a recovery is not a defect: the
`forall` arm is exactly this shape and is correct pending #2774. A gate that
fails on a judgement call gets muted, and a muted gate is worse than a list.

The one live hit is a lead, not a false positive: `parse_expr` over-consuming
across a newline (`FPGA_PART_35T and p100`), 8 fallback events across 3 specs.

Four tests, two of them for what it must NOT match.

Skill 176-178.

Refs #2754

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@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-08-29 05:13:18 UTC

Summary

Status Count
Total Open PRs 8
PRs with Failing Checks 7
PRs with All Checks Green 1
READY 0
FAILING 7
PENDING 0

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=347e84842d90 != 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 16e6afc into master Aug 29, 2026
33 checks passed
@gHashTag
gHashTag deleted the w699-abandoned branch August 29, 2026 05:24
gHashTag added a commit that referenced this pull request Aug 29, 2026
`parse-complete --show <spec>` is documented to print the tokens top-level
drop-recovery discarded, grouped by line. Since #2781 it printed the FALLBACK
view instead, and the token view was unreachable.

The `--fallbacks --show` arm was moved above the `--show` handler so it could
win when both flags are given, and its `if fallbacks` guard was left at the old
site. Nothing failed: both outputs are plausible, both name the file, both print
line numbers. The flag that selects between them was simply no longer read.

Found by using `--show` for something else and getting the wrong picture. There
is no test in this CLI that a flag still selects what it names -- which is how a
guard can be dropped in a refactor and nothing notices.

    parse-complete --show <spec>              -> 159 token(s) DISCARDED
    parse-complete --fallbacks --show <spec>  -> 11 whole-block fallback(s)

Refs #2754

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant