compiler: two frozen tests get the anchor their region needed - #3317
Merged
Conversation
`a_clocked_body_gets_no_return_guard` bounded its region with
v.split("always @(posedge").nth(1).unwrap_or("")
which degrades to the EMPTY string when the key is absent -- and an empty region
satisfies the absence assertion below it by construction. That single `assert!`
is the whole test body; `fn on_clock` appears as a fixture exactly once in this
file, in that test, so a rename of the emitted literal would leave it passing on
nothing.
`a_loop_outside_a_function_never_tests___t27_ret` bounded its region with
`rfind("endfunction")`. Its `.expect("the fixture declares a function")` cannot
fire and does not check what it says: `__mul_noop` is injected unconditionally,
so an `endfunction` is present whether or not the fixture declares one. The
subject sits inside the region only because `gen_verilog_module` happens to emit
its functions before its test-assertions section, and nothing asserted that
ordering.
Both now assert the subject is PRESENT before asserting anything is absent.
Controls, each mutant resealed so it could build at all:
break the clocked-block needle -> FAILED, "would pass over an empty region"
break the ordering needle -> FAILED, "not the one the assertion means"
`bootstrap/src/compiler.rs` is under the M5 freeze, so
`bootstrap/stage0/FROZEN_HASH` is resealed in this same commit:
ffccfa1a71cfd3b5... -> ab17ee37a00e3286...
The freeze refuses the build the moment the file changes, which is why every
mutant above needed its own reseal before it could be run.
Refs #3245
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
enabled auto-merge (squash)
September 5, 2026 18:05
Contributor
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
This was referenced Sep 5, 2026
gHashTag
pushed a commit
that referenced
this pull request
Sep 5, 2026
Two sessions of this loop ran concurrently and picked the same three tasks from the same list of recommendations, opening PRs for all of them (#3314, #3317). Nothing in the flow says who is working on what. `tri loop claim <name>` uses the one atomic operation git gives over a shared remote: creating a ref that does not exist. Exit 0 it is yours, 1 someone has it and the line names them, 2 the attempt could not be made -- which is not the same as being refused. THE OBVIOUS VERSION DOES NOT LOCK, and I measured it before writing this one. Pushing `origin/master` to the claim tag succeeds for the SECOND claimant too: git treats re-pushing the same value to an existing tag as a no-op and exits 0, so both sessions believe they hold it. Two sessions of this loop sit on the same `origin/master` almost by definition, so that lock would have been worse than none -- it reports success. The claim is therefore a commit no other claimant can produce: an empty tree with a message naming host, pid and HEAD. Measured: ALPHA exit 0, BETA exit 1 with the holder named. A refused push with NO holder exits 2, not 1. That is a broken push rather than a lost race, and reporting it as HELD would send the next session away from work nobody is doing. Two mutants killed -- borrowing the claim value from an existing ref, and reporting a broken push as held. The second test could not kill anything until it was fixed: it sliced from the first `match holder` to end of file and asserted `contains("exit(2)")`, which four unrelated exit-2 sites satisfy. CENSUS. Three moved and they are not all mine: fetches files read 43 -> 44 MINE: cli/tri/src/loopclaim.rs quiet named a path but not quiet 128 -> 127 already moved on master shell run: steps 235 -> 234 already moved on master A clean `origin/master` worktree fails `census pin --gate` with the last two before any change of mine, so the pre-commit hook has been failing for every author since a workflow edit landed unblessed. This commit carries the bless it inherited and says so rather than passing it on. Getting there took four wrong turns worth recording: `census pin` WITHOUT `--gate` exits 0 whatever moved, and I read that non-verdict as "nothing moved" twice -- once as the control that supposedly cleared master. Refs #3331 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Sep 5, 2026
Refs #3236 The only conflict was `bootstrap/stage0/FROZEN_HASH`. `compiler.rs` merged cleanly: master's change and this branch's two presence anchors both survive, and the diff against master is +27 lines with zero deletions. FROZEN_HASH is a DERIVED value, so both sides recomputed it against their own base and neither answer is right for the merge: this branch ab17ee37a00e3286ace8b4c281f71992464b4e350e8e3280783024d2105c1d0c master 60f03d78aecac0a0a070bb94d72e4b2578c37ade97d65c6f6793cb00456a3492 merged ca169bfed429665e761170e0337ed3423cc6649b6a0e1c444faf3f5227bef80e Taking either side would leave a seal that does not match the file it seals, and `bootstrap/build.rs` panics on that -- so the conflict cannot be resolved by choosing, only by recomputing. This is the same shape as the SKILL.md numbering collision: a value derived from the base, computed independently on two branches, where the merge and not either branch is where the defect appears. Controls: - build with the resolved seal -> exit 0 - build with a deliberately wrong one -> panics "FROZEN HASH violation", exit 101 The second is there because the first means nothing without it. t27c: 2557 passed, 0 failed across all test binaries (2559 listed, 2 ignored). `compiler::tests_w458::` runs 41, which includes both tests this PR adds.
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-09-06 02:14:54 UTC
Summary
Seal Status
|
gHashTag
added a commit
that referenced
this pull request
Sep 6, 2026
Two sessions of this loop ran concurrently and picked the same three tasks from the same list of recommendations, opening PRs for all of them (#3314, #3317). Nothing in the flow says who is working on what. `tri loop claim <name>` uses the one atomic operation git gives over a shared remote: creating a ref that does not exist. Exit 0 it is yours, 1 someone has it and the line names them, 2 the attempt could not be made -- which is not the same as being refused. THE OBVIOUS VERSION DOES NOT LOCK, and I measured it before writing this one. Pushing `origin/master` to the claim tag succeeds for the SECOND claimant too: git treats re-pushing the same value to an existing tag as a no-op and exits 0, so both sessions believe they hold it. Two sessions of this loop sit on the same `origin/master` almost by definition, so that lock would have been worse than none -- it reports success. The claim is therefore a commit no other claimant can produce: an empty tree with a message naming host, pid and HEAD. Measured: ALPHA exit 0, BETA exit 1 with the holder named. A refused push with NO holder exits 2, not 1. That is a broken push rather than a lost race, and reporting it as HELD would send the next session away from work nobody is doing. Two mutants killed -- borrowing the claim value from an existing ref, and reporting a broken push as held. The second test could not kill anything until it was fixed: it sliced from the first `match holder` to end of file and asserted `contains("exit(2)")`, which four unrelated exit-2 sites satisfy. CENSUS. Three moved and they are not all mine: fetches files read 43 -> 44 MINE: cli/tri/src/loopclaim.rs quiet named a path but not quiet 128 -> 127 already moved on master shell run: steps 235 -> 234 already moved on master A clean `origin/master` worktree fails `census pin --gate` with the last two before any change of mine, so the pre-commit hook has been failing for every author since a workflow edit landed unblessed. This commit carries the bless it inherited and says so rather than passing it on. Getting there took four wrong turns worth recording: `census pin` WITHOUT `--gate` exits 0 whatever moved, and I read that non-verdict as "nothing moved" twice -- once as the control that supposedly cleared master. Refs #3331 Co-authored-by: lab <lab@example.com> 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
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.
Fixes both tests in #3245, with the M5 reseal in the same commit.
a_clocked_body_gets_no_return_guardunwrap_or("")makes the region empty when the key is absent, and an emptyregion satisfies an absence assertion by construction. That single
assert!isthe entire test body, and
fn on_clockappears as a fixture exactly once inthis file — in this test — so a rename of the emitted literal would leave it
passing on nothing.
a_loop_outside_a_function_never_tests___t27_retRegion bounded by
rfind("endfunction"). Its.expect("the fixture declares a function")cannot fire and does not checkwhat it says:
__mul_noopis injected unconditionally, so anendfunctionispresent whether or not the fixture declares one.
The subject sits inside the region only because
gen_verilog_modulehappens toemit its functions before its test-assertions section. Nothing asserted that
ordering.
Both now anchor on presence first
The freeze
bootstrap/src/compiler.rsis under M5, sobootstrap/stage0/FROZEN_HASHisresealed in this same commit:
Worth noting for anyone doing this next: the freeze refuses the build the
moment the file changes, so each mutant above had to be resealed before it could
run at all. A first attempt at these controls produced silence rather than
failures, because the build never got as far as the tests.
Refs #3245