locate answers only for parse failures, and says what the item reproduces - #2892
Merged
Conversation
…uces
I set out to fix the 45 items `tri unparsed locate` had found -- "work without
research". Probing the first family killed it: `t *= 2.0;`, `float` parameters
and `f32` returns all COMPILE in isolation. The queued work was not work.
The cause is a fix that did not travel. Last pass `report` learned to split
lex / parse / typecheck / semantic stages; `locate`, one function away in the
same file, did not. Eight of its forty answers were TYPECHECK failures, where
"the item whose presence causes the failure" is a category error -- a type
error already names its line AND its reason (`cannot assign F64 to F32`), so a
bisection has nothing to add.
located AND causally confirmed 37
... the item ALONE reproduces 37 <- a minimal case, not a coordinate
candidate REFUTED by causality 37
nothing claimed 9
not a parse failure 10 typecheck + 4 lex
37 + 37 + 9 + 10 + 4 = 97
The second line is new and is the point. Whether a located item reproduces on
its own -- wrapped in a bare `module m { }` -- is the difference between a
minimal case and a coordinate. I checked all 37 by hand; now the command checks
them every run, and prints `(only in context)` beside any that does not.
`bootstrap/src/compiler.rs` untouched; FROZEN_HASH does not move.
Refs #2864
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
August 29, 2026 21:41
# Conflicts: # .claude/skills/ci-gates/SKILL.md
Contributor
PR DashboardGenerated at: 2026-08-29 21:52:59 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
gHashTag
added a commit
that referenced
this pull request
Aug 29, 2026
* Remove emitter_xdc from the corpus ledger; it passes now The corpus ratchet has been red on master for at least three consecutive runs and the reason is mine. #2897 fixed the string-literal inference bug and `specs/pins/emitter_xdc.t27` began to typecheck. I updated `tools/specs_generate_baseline.txt` and did not know about `docs/reports/suite_expectations.json`, which still listed the spec as expected-to-fail. An UNEXPECTED PASS is a ratchet failure by design: docs/CORPUS-RATCHET.md says "you fixed something. Remove the entry and lower max_entries". entries 151 -> 150 max_entries 151 -> 150 (down, the only direction the cap may move) RATCHET: CLEAN Control both ways: with the entry restored the ratchet reports `UNEXPECTED PASSES: 1` and exits 1; without it, exit 0. This is #2892's lesson one level up. That day I found a fix that had not travelled from one command to its neighbour; here it did not travel from one LEDGER to its sibling. When a repair makes a spec pass, grep every file that names the spec -- not only the ledger you happen to know. Refs #2864 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * skill: the second ledger Refs #2864 --------- Co-authored-by: Claude <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
2 participants
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.
I set out to fix the 45 items
tri unparsed locatehad found — the option I hadcalled "work without research". Probing the first family killed it:
t *= 2.0;fn a(x: float)fn a(x: f32) -> f32The queued work was not work.
The cause: a fix that did not travel
Last pass
reportlearned to split lex / parse / typecheck / semantic stages.locate— one function away, in the same file — did not. Eight of its fortyanswers were typecheck failures, where "the item whose presence causes the
failure" is a category error. A type error already names its line and its
reason (
cannot assign F64 to F32); a bisection has nothing to add.37 + 37 + 9 + 10 + 4 = 97.
The second line is the point
Whether a located item reproduces on its own — wrapped in a bare
module m { }— is the difference between "here is your bug in four lines" and"here is roughly where it starts". I checked all 37 by hand. That number would
have gone into a report as prose; it is now computed every run, and any answer
that fails the check prints
(only in context)beside it.What the answers look like
Each of these, alone in a module, fails — so each is a runnable reproducer, not
a coordinate.
Gates, run locally
specs generate 0 · specs parse 0 · conflict markers 0 · seals fresh 0 ·
types ratchet 0 · skill check 0 · unparsed probe 0 · unparsed locate 0 ·
cargo test -p tri0 (22 tests inunparsed.rs) ·rustfmt --check cli/tri/src/unparsed.rs0.bootstrap/src/compiler.rsis untouched, soFROZEN_HASHdoes not move.Refs #2864