Conversation
…he largest lever
Section 366 says the top first-error family in the C backlog was worth zero. It
is wrong, and the way it is wrong is the rule that same section teaches.
I counted files whose every error message mentioned `default_input` or
`valid_input`: 0 of 166, so every such file looked independently broken. But one
emitted template produces three errors and only the first carries the name:
__auto_type input = default_input(); // call to undeclared function
__auto_type result = f(input); // incomplete type 'void'
assert((result != {0})); // expected expression
Same construct. Grouping by message text is precisely what the census discipline
forbids, and I wrote that rule into the audit prompt before breaking it in my own
count an hour later.
Corrected, on 581 specs that generate C:
cc accepts as emitted 174
... with scaffold bodies emptied 265 (+91, upper bound)
... with the fix the sibling backends made 242 (+68, honest)
68 of a 404-spec gap -- the largest single lever in the project, called noise by
a census that looked rigorous.
What survives from 366 is the general claim: first-error ranking ranks by
position in the file, and single-family counting is the right instrument. What
fails is the worked example, because the instrument was fed message texts
instead of constructs.
The section adds the test that would have caught it: compile ONE construct alone
and count distinct messages. Greater than one means message-text grouping will
scatter it. Four lines gave three messages here.
Refs #2931
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
This was referenced Aug 30, 2026
gHashTag
added a commit
that referenced
this pull request
Aug 30, 2026
…the other way (#2935) * fix(tri): one population for the census, and a control that walks it the other way `unparsed report` said 5 typecheck failures; `unparsed locate`, in the same binary, said 2. Measured independently: 5 is right. Two causes, both in `locate`: * it walked its own corpus. `parse_failures` was lifted out last week with a doc comment claiming disagreement was "structurally impossible", but only `prose` was moved onto it -- `report` and `locate` kept their own `git ls-files` loops. The comment described an intention, not the code. * it checked whether the error named a LINE before it checked which STAGE refused the file. Three typecheck failures print `Typecheck FAILED (6 errors, 0 warnings):` and no line at all, so they never reached the stage check and were reported as "nothing claimed" -- a bucket that reads as "the parse question was asked and went unanswered", when the question does not apply. Its buckets summed to 80 against a population of 76. `report` and `locate` now read the shared scope, which carries the stage split; `locate_one` takes the error text the scope already has, so the file is compiled once for the population instead of three times per spec. Measured on all 76 parse failures: the in-place run and the temp-copy run named the same line every time and neither left a failure without one -- a reason to keep one ruler, not two. locate: 57 confirmed + 14 refuted + 5 silent = 76, the population exactly (was 57 + 14 + 9 = 80) stages: 5 typecheck + 4 lex + 1 semantic = 10, which is what `prose` prints New `tri unparsed agree`: the census asks git, this walks the working tree, and both must name the same population and the same stage split. Three commands reading one variable agree by construction, so their agreement measures nothing; this is the axis that can still be wrong. It also names what the census is blind to -- a spec on disk that git does not track. Mutation-checked, both directions: * a silent `specs/fpga/` filter in `parse_failures` -> DISAGREE, exit 1 * an untracked failing spec on disk -> named, gate stays green (the census legitimately speaks only of tracked specs; the point is naming it) * a second corpus walk in `prose.rs` -> `one_corpus_walk` FAILS * stage made to depend on the line -> the guard-order test FAILS Refs #2864 * skill(ci-gates) 371-373: a helper is not a cure; guard order; agreement that measures nothing 371 -- the shared `parse_failures` was written with a comment saying disagreement was now structurally impossible, and wired to one caller of three. A helper does not cure a class; the callers reading it do. The deliverable is the check that COUNTS the callers. 372 -- `locate` checked whether the error named a line before checking which stage refused the file, so three typecheck failures that print no line were filed as "nothing claimed". Its buckets still summed, and its test was still green, because the test asserted the classifier exists rather than the order it is applied in. 373 -- once all three commands read one scope, "do they agree" is a tautology. The field name is differential testing, and its precondition is independence: three commands reading one variable are one implementation under three names. Numbered 371-373 because master took 370 in #2932. Refs #2864 * docs(now): census population and the walk-the-other-way control (Refs #2864) * test(tri): `one_corpus_walk` reaches the subdirectories it claims to cover The first version read only the top level of `cli/tri/src`, so the five files under `src/depin/` could have grown their own corpus walk unseen. A control whose claim is wider than its reach is the defect it was written to catch, one level down. Mutation-checked: a walk planted in `src/depin/types.rs` now fails the test with `left: [("types.rs", 1), ("unparsed.rs", 1)]`. It did not before. Refs #2864
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
1 participant
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.
§366, merged an hour ago, says the top first-error family in the C backlog was
worth zero. It is wrong, and the way it is wrong is the rule that same
section teaches.
What I measured, and what is actually there
I counted files whose every error message mentioned
default_inputorvalid_input: 0 of 166. So every such file looked independently broken.One emitted template, four lines, three errors:
Errors two and three mention neither name. They are the same construct.
Grouping by message text is precisely what the census discipline forbids, and I
wrote that rule into the audit prompt before breaking it in my own count.
Corrected numbers
ccaccepts as emitted68 of a 404-spec gap — the largest single lever in the project (#2931), called
noise by a census that looked rigorous.
What survives from 366
The general claim: first-error ranking ranks by position in the file, and
single-family counting is the right instrument. What fails is the worked example,
because the instrument was fed message texts instead of constructs.
§370 adds the test that would have caught it: compile one construct alone and
count distinct messages. Greater than one means message-text grouping will
scatter it, and every file containing it will look independently broken.
It also records that the class was closed twice already — Zig in W585, Verilog in
W660 — and that W660's own comment names its sibling and stops there. Nobody
grepped the C path.
Refs #2931