tri abandoned: recoveries whose comment names what they discard - #2781
Merged
Conversation
…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>
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-29 05:13:18 UTC
Summary
Seal Status
|
This was referenced Aug 29, 2026
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>
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
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.
Refs #2754
Four defects closed on the W699 line were shapes the parser had already described in prose and never handled:
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: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()andgibberish 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:
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
forallarm 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_exprover-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