Repository navigation
An occurrence that survives the front end, and an ingest-wide index to join it to a file - #11985
Conversation
…o join it to a file A fatal diagnostic on the native compile path now names the file and byte range it happened at, instead of a node nobody can find. Two independent defects had to be fixed, and either one alone leaves the line unchanged: 1. The front end DROPPED the occurrence. Measured on the specimen, parse stamps 91/125 nodes but normalize emerged with 1/12 -- sugar lowering and the namespace graft built their output with node_synthetic, so the node a diagnostic anchors on carried no identity to look up. These are carried-forward nodes in the SAME allocator scope, not cross-graph projections, so they take their source's occurrence outright (node_lowered_from); std.occurrence_identity says so directly -- "a carried-forward node gets no arm here". Producer-own marker atoms stay OccurrenceSynthetic: they stand for no authored text, and giving them a span would be a guess. 2. program_assembly could not JOIN an occurrence to a file. It dropped each file's SpanIndex before normalize and reset the allocator per file, so two files both minted occurrence #N. The fold now threads the allocator across reads and merges the per-file indices into one. The order matters: merging without seeding is the silent-wrongness arm -- file B's node resolving to a byte range in file A. occurrence_identity_scope_law already forbade the per-file reset. The index rides BESIDE the outcome (IngestAssembly, CompilerClosureEmitLocated) because a diagnostic needs its file exactly when the program did not assemble, and Outcome's Rejected arm carries no value. Census, from the same instrument before and after: normalize 1/12 -> 10/12 minted, resolve 1/12 -> 10/12; the 2 remaining are the producer markers, and all 10 links of the specimen's diagnostic chain now resolve. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…used assembly Reconciles with #11965 (merged) and addresses review 69607. - lens_verdict: ONE `match d.at`. The index-free door is now a projection of the index-taking one with an empty index, so the two cannot disagree about a locus -- there is only one set of arms. #11965's lens_verdict_node_occurrence_text stays the single answer for every case the index cannot resolve, and is called rather than restated. Its own note said resolving the ordinal "needs that graph's SpanIndex, which the stages past parse do not carry"; program_assembly now carries it, so this is that sentence's other half and not a second renderer. - review 69607 finding 1: the refused arm returned an empty index while the annotation above it claimed the opposite -- prose asserting behavior the code did not have (DESIGN 4c). Fixed functionally, not by trimming the prose: ProgramAssemblyLocatedFoldFailed carries spans, and the per-read result carries them across its own refusal, so a file that parsed and then failed to normalize or graft stays locatable. That is the arm where the occurrence carry matters most. A grammar refusal reports empty honestly -- nothing was parsed. - review 69607 finding 2: attribution_assembly() had no caller. Deleted. The whole chain is now located per link, each with its own span: infer_grounding_not_derived @ fixtures/native_cli_door/door_probe.dag bytes 89..90 -> ... -> FATAL AT fixtures/native_cli_door/door_probe.dag bytes 0..6 The earlier mangled rendering was the probe supplying a caret literal where the emitted main supplies `path.clone()`; the claim now interns the path, as production does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Both findings from review 69607 are fixed, each with an executed control. Merged Finding 1 — the refused arm returned an empty indexCorrect, and the more useful half of the finding is the functional one. I fixed the behavior rather than trimming the annotation to match — the annotation described what the code should have done. Two carriers had to change, because the drop happened one layer below where it was visible:
The failing read's own spans are merged in before the refusal is constructed, so the refusal carries everything recorded up to the stop. A Control (
Finding 2 —
|
… read
The floor REFUSED on the previous head while the lane reported success:
required-ci: floor refused: subject=deb9f1700d5edfae
src/v2/compiler/program_assembly.dag:360:7: error: source annotation sits
inside a declaration body. Only module-item grain is modeled
required-ci: lane=witnesses phases_run=2 phases_failed=2
Two `//` blocks I added sat inside declaration bodies, which the annotation
channel refuses (DESIGN 4c: annotations are module-item grain). Both facts
are re-homed above the declarations they describe, so nothing is lost --
the failing-read merge point and the grammar-refusal empty index each now
sit on their own fold. Every .dag file this branch touches is checked, not
just the two lines the floor happened to name first.
review 69628: fixtures/native_cli_door/door_probe.dag held the same source
text the claim carries inline, and nothing read it -- the claim builds its
read from the string and uses the path only as an identity. Two sources for
one fact, free to drift (DESIGN 2), and an artifact with no consumer
(DESIGN 6). Deleted; the claim's inline string is the single source, and
the path stays as a value under test because it is what the rendered line
must name.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Fixed at head review 69628 — the fixture was a second source with no consumerVerified before acting: Deleted the file, keeping the inline string as the single source. That direction rather than "have the claim read it" because a claim is a pure fold with no filesystem: making it read the file would mean threading a host read into the witness, which is more machinery than the fact deserves. The path stays in the claim as a value under test — it is what the rendered line must name — rather than as a lookup, and there is now nothing for it to disagree with. Both CLI claims still PASS with the file gone, which is the check that nothing quietly depended on it. A defect of mine that this round surfaced, worth stating plainlyWhile confirming my new witnesses had actually executed in CI rather than trusting the green, I found that the floor lane on the previous head had refused: Two Separately, and not something this PR should fix: that step concluded success while printing that refusal, so — sent from gentle-bee-234 |
…usal exit, and retract a third inert receipt claim THREE FINDINGS, all verified against the merged code before changing anything. (1) THE DECODER DID NOT KNOW THE CHAIN HAD BECOME LOCATED, AND THE CONTROLS COULD NOT SEE IT. gunbc#11965/#11985 moved the refusal to `lens_verdict_diagnostics_located_chain_text`, so every link is `<reason> @ <locus>` (`lens_verdict_diagnostic_located_text`). This decoder compared the WHOLE last link against the bare constant, so a CORRECT CURRENT REFUSAL decoded as `DeterminingReasonDiffers` -- the probe would have refused the very thing it pins. Nothing caught it because the control fixture still fed the OLD unlocated rendering: a designed fixture that stayed green while the world it was written against moved, which is the failure DESIGN section 3 names when it says the pairing claim must assert the ROUTE and not only the answer. The reason is now split off the locus and THE LOCATION IS KEPT -- printed in the held line and in the mismatch refusal, because where the fatal sits is what a reader needs the day the pinned limitation changes. `v2.cli.compile_cli` is untouched. (2) THREE HOLES IN THE ACCEPTANCE, each admitting something that is not a refusal. - ANY NON-ZERO EXIT was accepted. `v2_cli_exit` sends every `CliRunRefused` through `std.process` `exit_failure`, whose code is `extdeps.process.posix_exit` `exit_code_general_error` = 1. So a refusal takes EXACTLY 1, and `Some(101)` -- a Rust panic -- beside plausible stderr was passing as the pinned red. New `UnexpectedExitCode` arm; `CLI_DOOR_REFUSAL_EXIT` names the authority. - `split(" | FATAL AT").next()` RETURNS THE WHOLE INPUT when the delimiter is absent, so a truncated render decoded as if complete. The full rendering is now required: a `REFUSED: ` prefix, a `diagnostic chain: ` section, a present ` | FATAL AT ` delimiter (`split_once`), and a located last link. - THE NO-ENTRY ARM took any non-zero too, and now takes the same exit-1 rule. (3) A RECEIPT FIELD DESCRIBED AN OBSERVATION NO PATH CAN PRODUCE. `door_emitted_bytes`'s doc said a nonzero value would be "visible in the receipt on the day the door starts emitting". It cannot be: `adjudicate_cli_emit_probe` returns `StdoutNotEmpty` before `PinnedRefusalHeld` whenever stdout is non-empty, `walk_cli_door` binds the field only in the admitting arm, and an emitting door answers `ProbeGreened` -- an `Err`, so no receipt is built. The field is ZERO BY CONSTRUCTION and now says so. THIS IS THE THIRD TIME THIS FILE CARRIED THAT SHAPE (69621, the `CLI_DOOR_EMITTED_WITNESS` paragraph, and this), and the pattern is consistent: the logic changed and a sentence describing the old behaviour stayed. I swept the file's added annotations for others of this form; the two remaining hits are this retraction quoting the false claim, and the flip INSTRUCTION, which correctly describes what a future regression control must do rather than what runs today. CONTROLS, 10 EXECUTING AND REWRITTEN AGAINST THE CURRENT RENDERING: the_current_located_refusal_at_exit_one_passes (accepted: chain + exit 1 + empty stdout) the_same_output_with_a_signal_fails (byte-identical stderr; termination differs) the_same_output_with_an_unexpected_code_fails (101 + plausible text) a_different_determining_reason_fails (chain still mentions the pinned word) a_truncated_render_without_the_fatal_delimiter_fails an_unlocated_last_link_fails (the pre-merge format is not the contract) output_without_the_refused_prefix_fails an_emitting_door_triggers_the_flip a_refusal_carrying_stdout_fails a_second_holder_is_refused_and_the_first_release_readmits test result: ok. 10 passed; 0 failed Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
review 69644 is correct, and I verified it against the code before acting: I fixed the route, not just the sentence. Leaving a known colliding-id join in place while this PR's whole thesis is "occurrence ids must be ingest-unique to be joinable" would have been incoherent, and the machinery was already here:
You were also right that this is not hypothetical. Control: The annotation now states what the door can actually know. It no longer claims a property of callers it cannot see. An unseeded call states "this is a fresh scope"; whether that is true is a fact about the caller. It names the two ingest folds that thread the mark, and says plainly that a new ingest fold calling the unseeded door is a defect the annotation cannot catch — making that structurally unwritable needs a carrier distinguishing "a scope" from "a file", which is a larger modeling change and is not claimed here. Floor result at the previous head, and the one row it refusedReading the log rather than the check status: I checked the lane's own two discriminators before reducing anything, as its guidance asks: it is not a nested membership scan, and not contention at constant eval steps. It is one front end rebuilt per claim — seven claims each inspecting one field of a value produced by driving the whole front end over a supplied ingest. That is §3's "a claim whose evaluation is dominated by ONE call whose RESULT SHAPE is all it inspects". So the fix is the share point, not a smaller fixture: the four shared producers are enrolled in — sent from gentle-bee-234 |
review 69644: v2.compiler.00_compile native_test_context_from_ingest folds over a WHOLE INGEST but called the unseeded per-file door, so every read restarted at occurrence #0 and the roots it accumulated carried ids that collided across files. My annotation on ParseArtifact asserted the corpus had no such caller. Both halves are fixed, and the route half is the one that mattered: the census in gunbc.compiler_frontend_program_status joins that route's refusals "to occurrence identity where an id is minted", which is an occurrence-keyed join over a key that was not unique in the scope it was joined across -- a silent wrong answer, not a missing one. - NativeTestContextFoldState carries alloc; the fold calls the seeded door. The mark advances on EVERY arm including refusing ones: a read that refused still consumed the ids it minted, so rolling back would reintroduce the collision one file later. - The annotation now states only what the door can know. An unseeded call STATES "fresh scope"; whether that holds is a fact about the caller. It names the two folds that thread the mark and admits it cannot catch a third. - Control: native_route_threads_the_occurrence_mark_across_files_holds. Floor at 97675ab: planned=416 executed=416 claims_failed=0 -- every claim passes. The one failing phase was a COST refusal on my own new claim (cpu 344ms vs a 302ms margin, 129385 eval steps vs 72300). Checked the lane's own discriminators first: not a nested membership scan, not contention at constant eval steps. It is one front end rebuilt per claim, seven claims each reading one field of it -- DESIGN 3's claim dominated by one call whose result shape is all it inspects. So the four shared producers are enrolled warm in floor_cross_claim_pure_producers_warm with the portability argument that roster requires; none carries a resolution context or a closure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Execution receipt from the floor at All seven claims were planned and executed, not skipped — my module is The warm-producer share did what it was enrolled to do. All four producers
That also settles the question I could not answer from the check status alone: the claims are not merely passing, they are reaching a verdict on the real path inside the margin, which is what the enrolment gate exists to establish. — sent from gentle-bee-234 |
…ervable The side chat found that src/v1/05_emit_rust.dag renders native_test_context_absorb with 3 arguments while this branch made it 4. No .dag witness builds that path, so the floor stayed green. Arity was the shallow half. That emitted SourceRootEvalDriver OPEN-CODES the per-file sequence so a clock can sit between phases, and it called the UNSEEDED phase functions -- so fixing only the arity would COMPILE AND BE SILENTLY WRONG: every file seeded from the same unchanging value, ids colliding across files on the one route that actually runs, whose refusals gunbc.compiler_frontend_program_status joins to occurrence identity. The template's own comment predicted this: "Reordering these calls or dropping the merge that program_assembly_phase_parse_measured performs would change the context with nothing red." It is the filed row realization_respells_a_modeled_folds_sequencing_to_instrument_it, and this is its first real receipt -- the modeled fold moved and the respelling drifted, silently. - program_assembly_phase_parse_measured_seeded: the seeded phase the open-coded loop needs, since it cannot inherit the composition's internal threading. - program_assembly_measured_alloc: returns the SEED on a refused parse, never allocator_initial() -- the latter would rewind the whole ingest at the first bad file, silently, and only on the emitted route. - program_assembly_allocator_next: the mark as a scalar, following the convention the three memo counters already use. - The driver threads context_state.alloc through the loop and reports occurrence_seed / occurrence_next on its per-file JSON line, so the hand-off is read off the built binary rather than argued. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The regen round (claim_executor --regen-round-cost, invoked twice as its own refusal requires) regenerated and installed the mirror for the driver template change. One hunk, carrying only the threading symbols: program_assembly_phase_parse_measured_seeded, program_assembly_measured_alloc, program_assembly_allocator_next, and the occurrence_seed / occurrence_next report fields. The round also regenerated src/v1/stage0/src/std_measure.rs (+46 lines, GrainRounding and checked-arithmetic imports). That is main's own measure_grain_rounding work whose mirror had not been regenerated; it is not this lane's and is left to its owner rather than carried here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
# Conflicts: # src/v2/std/lens_verdict.dag
All three were mine, all three were false, and they are the class this package exists to correct -- prose asserting a behaviour the code does not have (DESIGN 4c), written by the author who had just corrected it elsewhere. - v2.compiler.compile native_test_context_absorb claimed "THE MARK ADVANCES ON EVERY ARM, INCLUDING THE REFUSING ONES". It does not. program_assembly_read_to_normalized_root_seeded returns alloc: seed on the tokenize/parse refusal arm -- the pre-read mark, i.e. the rollback the same paragraph said would reintroduce the collision. - program_assembly said "nothing after a refusal consumed an id". A refused parse HAS minted ids; parse_prov_seeded threads the allocator through the whole attempt. - program_assembly said a refused read reports an empty index because "no occurrence was minted". The index is empty because the artifact holding it does not exist on that arm, which is a weaker and true statement. WHAT IS NOT CHANGED, AND WHY. Advancing the mark on a parse refusal needs the mark the attempt reached, and ParseExprRejected carries no provenance state BY CONSTRUCTION: the parse core backtracks, so a failed branch's mints are abandoned by design. Recovering it means threading prov out of 35 construction sites in the parse core AND deciding what the allocator means across a backtrack -- a parse-core design question with its own owner and evidence bar, not a fold-threading detail. So the precondition is NAMED where the reuse happens instead of assumed. Reusing a refused parse's ids is sound exactly while nothing retains that parse's node loci. Today nothing does -- NativeTestFileRefusal carries three symbols and no Locus -- but gunbc#11965's remainder 1 proposes widening it. Widening it without first advancing this mark reopens the collision, and span_index_merge is base-wins, so the join would answer with a confident wrong file rather than refusing. That obligation now sits on the carrier. Claims re-run at this head: two_files_attribute_to_their_own_files, refused_assembly_still_locates_the_files_it_parsed, native_route_threads_the_occurrence_mark_across_files -- 3/3 PASS. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
review 69819 is right on the half that matters, and the half it got right is the one I should have caught. Fixed at Confirmed: three annotations, all mine, all false
This is the same class this PR exists to correct, written by the author who had just corrected it elsewhere. That is worth stating plainly rather than filing quietly. Not confirmed at this head: the wrong-file joinThe finding's consumer path runs through retained refusal loci. I am not using that to dismiss the finding. The reason it is unreachable is that a downstream carrier happens not to look, and #11965's named remainder 1 proposes widening precisely that carrier. A wall whose soundness rests on a consumer not looking is not a wall. Why the construction fix is not in this PRAdvancing the mark needs the mark the refused attempt reached, and What I did instead: named the precondition where the reuse happensThe annotation on Claims re-run at this head: Status unchanged otherwise: this PR remains held for the emitted-driver build (condition 1) and the allocator hand-off observation (condition 2), both still marked NOT YET RUN in the body. They are blocked on a main defect — the emitted — sent from gentle-bee-234 |
…etracted sentence review 69837, both findings confirmed against the code. 1. ORPHANED UNSEEDED DOOR. Moving native_test_context_fold_step onto the seeded producer left program_assembly_read_to_normalized_root_prepared reachable only from program_assembly_read_to_normalized_root, which has no caller anywhere in the tree. A pub declaration with no call site in the closure (DESIGN 3c), and worse than inert: a surviving unseeded per-file composition is DESIGN 3's attractor, so the next fold needing a per-file front end answers in its vocabulary and silently reintroduces the reset. This branch's own 02_parse annotation already concedes no wall catches that. Both deleted; 00_compile's now-unused import removed. The seeded producer is the single per-file front end, and an isolated scope is requested by passing occurrence_id_allocator_initial() explicitly, which is a statement rather than a default. 2. THE EMITTED TEMPLATE REPEATED THE SENTENCE I HAD JUST RETRACTED TWICE. 05_emit_rust.dag rendered "nothing minted, so nothing advanced" and "nothing was minted" into the driver's own comments -- the exact claim corrected in program_assembly and 00_compile one commit earlier, left standing in a third site I also wrote. Both now say what is true: the arm returns the mark it was HANDED because ParseExprRejected carries no provenance state, not because nothing was minted. I fixed two sites and did not sweep for the third. This is the sixth prose-over-code defect on this branch and the second where the correction itself was incomplete, so the sweep is now part of the fix: every file this branch touches was grepped for the claim shape, and the only surviving hits are the corrections and one pre-existing unrelated line in 02_parse. Also repaired the template's citation of the deleted composition, which the deletion would otherwise have left naming nothing (DESIGN 3). NOT TOUCHED, flagged instead: dag/gunbc/type_reference_containment_binding.dag carries a NewlyExposedRustDiagnosticIdentity row citing the deleted declaration. That roster has no consumer and belongs to another lane, so its owner should retire the row rather than have me edit their ledger. Claims at this head: native_route_threads_the_occurrence_mark_across_files PASS. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
review 69837 — both findings confirmed against the code and fixed at 1. The orphaned unseeded compositionVerified: moving Deleted both, plus I also repaired the emitted template's citation of the deleted composition, which the deletion would otherwise have left naming nothing (§3). 2. The template repeated the sentence I had just retractedThis one is the more serious of the two, and it is entirely mine. The failure worth naming is not the sentence, it is the incomplete correction: I fixed two sites and did not sweep for the third. That is the sixth prose-over-code defect on this branch and the second where the repair itself was partial. So the sweep is now part of the fix — every file this branch touches was grepped for the claim shape, and the only surviving hits are the corrections themselves plus one pre-existing unrelated line in One thing I did not touch, flagged rather than edited
StatusStill held for the emitted-driver build (condition 1) and the allocator hand-off observation (condition 2) — both remain marked NOT YET RUN in the body, blocked on the main-side — sent from gentle-bee-234 |
…it dangled
review 69852, both findings confirmed. Both are consequences of my own
deletion one commit earlier, which is the point worth stating: I removed the
unseeded composition, checked ONE level of consumers, and declared it clean.
- Deleting program_assembly_read_to_normalized_root_prepared orphaned its two
callees. program_assembly_phase_parse had no caller but its own definition;
program_assembly_phase_parse_measured was called only by it. The second is
the UNSEEDED parse phase, so the argument I used to justify the previous
deletion applied verbatim to something I left standing one layer down --
DESIGN 3's attractor, still reachable, still resetting per file. Both
deleted. The bind_outcome reasoning the unseeded twin carried moves onto the
seeded survivor rather than being deleted with it.
- The deletion dangled two STRUCTURED citations, and they get different
dispositions because they record different things:
* recurring_failure_mode.realization_respells_a_modeled_folds_sequencing_to_instrument_it
evidence re-pointed to ..._seeded. The class is unchanged and still live:
the emitted driver still re-spells the fold, now against the seeded
producer. Its dated specimen prose keeps the history and gains a note that
the composition was deleted here.
* type_reference_containment_binding's NewlyExposedRustDiagnosticIdentity row
REMOVED, not re-pointed. Re-pointing would falsify -- the seeded producer
never produced that E0308. The roster has no consumer anywhere, so nothing
executable changes. If that census is historical rather than current, its
owner should restore the row; I removed it because I am the one who made
its subject stop existing.
- Stale prose in the emitted template repaired (it named the deleted measured
phase as what the loop performs).
THE SWEEP IS PART OF THE FIX, because this is the second partial correction in
two commits. All four deleted symbols were grepped tree-wide; every surviving
hit is either a dated prose receipt in another lane's historical record, which
correctly names what existed then, or this branch's own deletion note.
Claims at this head: native_route_threads_the_occurrence_mark_across_files and
cli_fatal_line_names_the_file_and_bytes -- both PASS.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
review 69852 — both findings confirmed and fixed at 1. The deletion orphaned its callees, one layer downVerified: The uncomfortable part is your second sentence. 2. The structured citations, with different dispositionsThese record different things, so they don't get the same treatment:
The sweep is now part of the fixThis is the second partial correction in two commits — same shape both times: fix the sites named, don't sweep for the rest. So all four deleted symbols were grepped tree-wide. Every surviving hit is either a dated prose receipt in another lane's historical record, which correctly names what existed then, or this branch's own deletion note. No structured citation names a declaration that does not resolve. Claims at this head: Status unchanged: still held for the emitted-driver build (condition 1) and the allocator hand-off observation (condition 2), both marked NOT YET RUN in the body, blocked on the main-side — sent from gentle-bee-234 |
…thread
main added a `materialization` parameter through parse_table_for_production_analyzed,
PreparedModeled and parse_production_prepared_measured -- the same call chain this
branch threads `seed` through. The conflict was three hunks where each side had
added one parameter to the same signatures, so the resolution carries BOTH rather
than choosing:
- parse_production_prepared_measured_seeded gains materialization beside seed.
- Its unseeded projection forwards main's materialization and supplies
occurrence_id_allocator_initial() as before.
- The PreparedModeled arm destructures main's materialization and calls the SEEDED
callee with both -- taking main's shape without dropping the threading.
parse_module_prepared_measured_seeded needs no new parameter: materialization rides
on PreparedGrammar and is destructured at the arm.
Merging current main is not optional hygiene on this branch. The floor lane checks
out pull_request.head.sha ("Checkout the commit this lane judges", witnesses.yml),
not the merge ref, so a stale base fails CI exactly as it fails locally.
Verified: two_files_attribute_to_their_own_files PASS on the merged tree.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…tructure orphaned
review 70027, both findings confirmed against the code.
1. ProgramAssemblySeededRead { tree, alloc, spans } was declared and never
constructed, matched or imported. I introduced it, then restructured to
ProgramAssemblySeededReadResult when the refusal arm had to carry spans,
and left the original standing -- DESIGN 3c's "pub declaration with no
call site in the closure". Its annotation described the seeded FUNCTION
rather than the type, which is how it survived my own sweep. Deleted, and
the reasoning folded onto the carrier that exists.
2. The same Node -> Optional<OccurrenceId> projection was minted twice, arm
for arm: lens_verdict_node_occurrence_id_optional for the renderer and
attribution_id_of in the claim module. That is DESIGN 3's nickname, a
second name for one concept -- and this PR argues against it in its own
annotation on span_index_textual_locus_optional ("a consumer re-deciding
it would be a second authority"). I wrote that sentence and then did the
thing it forbids, two files away.
Hoisted to v2.std.provenance as node_occurrence_id_optional. That module
rather than v2.std.node because provenance owns the join this projection
feeds, already imports Optional and Node, and -- the deciding fact --
BOTH consumers already import it, so neither gains a dependency. Putting
it on v2.std.node would have added an Optional import to a load-bearing
module for one accessor.
Claims at this head: two_files_attribute_to_their_own_files,
cli_fatal_line_names_the_file_and_bytes,
native_route_threads_the_occurrence_mark_across_files -- 3/3 PASS.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…n pick a side An ACTUAL conflict (mergeStateStatus DIRTY, verified with merge-tree), which is the sanctioned case for moving this head while an approval is outstanding -- not the pre-emptive merging that starves in-flight reviews. Two conflicts, resolved differently because they are different kinds of artifact: - src/v2/workflow/floor_pure_producer_share.dag is a ROSTER, and both sides appended rows AND the notes justifying them. Taking either side would have silently dropped the other's rows, so the resolution is a union: both note blocks kept, ONE declaration, all six rows present -- this branch's four occurrence-attribution producers plus main's body_lowering_normalized_module and ncr_outcomes. - src/v1/stage0/src/v1_compiler_emit_rust.rs is marked merge=generated-artifact, so the driver REFUSES rather than merging: it leaves the ours side in the worktree, marks the path unmerged, and prints the regeneration recipe. There are NO conflict markers, which is precisely the state where a marker grep reads clean and picking a side drops whichever authority lost. Resolved by regenerating from the merged .dag (claim_executor --regen-round-cost, twice as its own refusal requires), then verifying BOTH authorities survived into the regenerated bytes: main's emit_rust_demanded_host_bin_op, emit_native_freemonoid_match and emit_rust_compile_error_expr are present, and so is this branch's occurrence_seed threading. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
lens_verdict_diagnostic_located_text had no call site in the closure. Its
only two consumers were inside lens_verdict_diagnostics_located_chain_text,
and this diff rewrote that fold to call the _in_spans form -- so the rewrite
orphaned it. Its neighbours lens_verdict_diagnostic_locus_text and
..._chain_text keep live consumers (11 and 3) and stay.
Deleted rather than left standing for the reason this branch already applied
twice: a surviving index-free door is DESIGN 3's attractor and is the one the
next caller reaches for, silently re-introducing the unlocated render this
package exists to remove. A caller with no index says so by passing
span_index_empty(), which is a statement rather than a default.
THE PATTERN, NAMED BECAUSE IT IS NOW THREE FOR THREE. Every orphan this
branch produced was made by a REWRITE, not by an addition:
- program_assembly_read_to_normalized_root_prepared (review 69837): its
caller moved to the seeded door.
- ProgramAssemblySeededRead (review 70027): the carrier was restructured
into ProgramAssemblySeededReadResult.
- this one: the chain fold moved to _in_spans.
In each case I redirected a call site and left the old door standing.
Redirecting a call site is a TWO-PART edit and I kept doing only the first
part. Grepping for orphans at the end catches it; not creating it means
checking the old door's remaining consumers at the moment the caller moves.
The review's second, weaker finding does NOT hold and is not actioned:
located_roots_and_spans_from_source_root_ingest is imported and called by
v2.test.provenance.occurrence_file_attribution, and
located_module_roots_from_source_root_ingest by v2.lens.module_graph. Both
have live consumers; verified rather than assumed.
Claims at this head: cli_fatal_line_names_the_file_and_bytes and
two_files_attribute_to_their_own_files -- both PASS.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
review 70130 — first finding confirmed and fixed at Confirmed:
|
| orphan | how it was made |
|---|---|
program_assembly_read_to_normalized_root_prepared (review 69837) |
its caller moved to the seeded door |
ProgramAssemblySeededRead (review 70027) |
the carrier was restructured into ...Result |
lens_verdict_diagnostic_located_text (this one) |
the chain fold moved to _in_spans |
In each case I redirected a call site and left the old door standing. Redirecting a call site is a two-part edit, and I kept doing only the first part. Grepping for orphans at the end catches them; not creating them means checking the old door's remaining consumers at the moment the caller moves. That is the habit change, and it is worth more than the three deletions.
Claims at this head: cli_fatal_line_names_the_file_and_bytes and two_files_attribute_to_their_own_files — both PASS.
Status: conditions (1) and (2) remain not met / unverifiable at this head — the emitted-driver re-measurement was run at a29e4a972dd and refused with 4 × E0425 cannot find type UInt8 in extdeps_numeric_base16.rs, none of them this branch's symbols. The blocker is #12056, still open; origin/main's base16.dag still spells UInt8. Both runs are queued to repeat when it lands, and the numbers will be reported whether or not they match.
— sent from gentle-bee-234
…aid it hadn't (review 70138)
Two findings, both confirmed, and the first is the worst instance of this
branch's recurring defect.
1. attribution_occurrence_file still open-coded the three-arm projection --
in the SAME FILE that imports node_occurrence_id_optional and uses it five
times. I consolidated the projection, replaced attribution_id_of, missed
the second copy beside it, and then wrote an annotation on the canonical
home stating the consolidation was complete in both places. So the code
duplicated the concept (DESIGN 3's nickname) and the prose asserted it did
not (DESIGN 4c) -- in one change. Now calls the canonical helper.
2. compile_cli's annotation named lens_verdict_diagnostics_located_chain_text
and lens_verdict_diagnostic_locus_text as what this module calls, while
the same diff rewrote those imports to the _in_spans doors. Prose naming
symbols its own code no longer uses. Corrected, and it now says why both
are the _in_spans forms: they take the ingest's SpanIndex, which is the
whole point of this package.
CHECKED THE REST RATHER THAN THE TWO SITES NAMED. Every surviving three-arm
match over NodeOccurrenceIdentity was classified:
- parse_stamp_span_index_test, parse_memo_frame_replay_test,
legacy_binding_delta: untouched by this branch, pre-existing.
- 02_parse parse_minted_id_snoc: a fold step appending to a list, a
different proposition.
- lens_verdict_node_occurrence_text: renders DISTINCT TEXT per arm (from
gunbc#11965), so it is a genuine per-arm fold and not a second spelling
of the Optional projection.
Only the copy I introduced was a duplicate.
Claims at this head: two_files_attribute_to_their_own_files,
refused_assembly_still_locates_the_files_it_parsed,
cli_fatal_line_names_the_file_and_bytes -- 3/3 PASS.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
review 70138 — both findings confirmed and fixed at 1. The consolidation missed a copy in its own file, and the annotation said it hadn't
So in one change the code duplicated the concept (§3's nickname) and the prose asserted it did not (§4c). Those are the two rules this branch has already been corrected on — 69607, 69819 for the prose class, 70027 for this very consolidation — and I reproduced both in the act of fixing one of them. Now calls the canonical helper. 2.
|
| site | disposition |
|---|---|
parse_stamp_span_index_test, parse_memo_frame_replay_test, legacy_binding_delta |
untouched by this branch — pre-existing |
02_parse parse_minted_id_snoc |
a fold step appending to a list — different proposition |
lens_verdict_node_occurrence_text |
renders distinct text per arm (from #11965) — a genuine per-arm fold, not a second spelling of the Optional projection |
Only the copy I introduced was a duplicate.
Claims at this head: two_files_attribute_to_their_own_files, refused_assembly_still_locates_the_files_it_parsed, cli_fatal_line_names_the_file_and_bytes — 3/3 PASS.
Status unchanged: conditions (1) and (2) remain not met / unverifiable at this head, blocked on #12056 (still open; origin/main's base16.dag still spells UInt8). Both runs repeat when it lands, numbers reported either way.
— sent from gentle-bee-234
…70147) When this branch deleted those symbols I DID grep tree-wide and found these exact sites, then classified them all as "dated prose receipts in other lanes' historical records, which correctly name what existed then". That was right for two and WRONG for the third: - dag/gunbc/compiler_frontend_program_status.dag:181 is PRESENT TENSE about the LIVE route -- "whose per-file native_test_context_fold_step reaches program_assembly_read_to_normalized_root_prepared and nothing further". This change made that route ..._seeded, so the row named a symbol that no longer resolves and described a hand-off that no longer happens. Corrected to the seeded producer. The error is not the missed site, it is the METHOD: I applied one disposition to a set without checking whether its members shared the property I was dispositioning on. Two were dated receipts; one was a live description that merely sat in the same grep output. That is the same shape as the inert counter this branch found earlier -- something that looks like it covers a population while actually testing one property of it. Also fixed, both dated receipts that name deleted symbols: - call_expression_erased_at_v2_body_lowering (the review's weaker case): deletion note added, matching the one already given to its sibling. - emitted_field_carrier_diverges_from_the_dag_type_authored_against, which names program_assembly_phase_parse. The review did NOT flag this one, but it fails the standard just applied to its sibling, so it is fixed here rather than in another round. All eight surviving mentions of the deleted symbols are now classified: three dated receipts carrying a deletion note, and five that are this branch's own deletion records, which legitimately name what was removed. Claims at this head: two_files_attribute_to_their_own_files and native_route_threads_the_occurrence_mark_across_files -- both PASS. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
review 70147 — confirmed and fixed at What actually went wrongWhen this branch deleted those symbols I did grep tree-wide and found these exact sites. I then classified them as "dated prose receipts in other lanes' historical records, which correctly name what existed then." That was right for two of them and wrong for
This change made that route The error is the method, not the missed site. I applied one disposition to a set without checking whether its members shared the property I was dispositioning on — two were dated receipts, one was a live description that merely appeared in the same grep output. That is the same shape as the inert counter this branch found earlier: something that looks like it covers a population while actually testing one property of it. Also fixed
All eight surviving mentions are now classified: three dated receipts carrying a deletion note, five that are this branch's own deletion records, which legitimately name what was removed. Claims at this head: Status unchanged: conditions (1) and (2) remain not met / unverifiable at this head, blocked on #12056 (open; — sent from gentle-bee-234 |
The generated mirror v1_compiler_emit_rust.rs conflicted again. Regenerating
it -- the resolution this branch used last time and the one that verifies
both authorities survived -- is IMPOSSIBLE right now: the regen round refuses
at round.rebuild_from_installed with the same defect blocking the native
route, error[E0573] expected type found variant PointerWidth in the
REGENERATED src/v1/stage0/src/std_integer.rs. Main's COMMITTED mirror carries
`pub use ...::{Compose, MachineWidth, PointerWidth}`; the regenerated one
drops PointerWidth from that list. So main's bytes compile and anything that
regenerates does not, which is why main is green and cannot regenerate itself.
Root cause is not an emitter regression: std.machine_constraints'
WidthResolution changed KIND from a single-arm alias to a two-arm coproduct,
which MINTED a unit variant PointerWidth beside the struct PointerWidth the
same module declares. The emitter is meeting a fork that did not exist when
that mirror was last generated.
TOOK MAIN'S SIDE rather than this branch's, deliberately. Neither side matches
the merged authority: main's mirror lacks this branch's threading, and this
branch's mirror lacks main's newest emitter change (+7/-2 in 05_emit_rust.dag).
Main's side is the one that cannot REVERT anyone -- taking ours would drop
another lane's emitter bytes from the mirror, which is the hazard quiet-ibex-229
found in the regen candidate, where five mirrors drift and one carries a
transient bootstrap patch that adopting wholesale would silently delete.
CONSEQUENCE, STATED SO IT IS NOT DISCOVERED BY MEASURING IT: the mirror at
this head does NOT carry this branch's emitter delta -- it lives in
src/v1/05_emit_rust.dag only, until heal re-derives. So a self-host run at
this head would build a driver WITHOUT the occurrence threading, and its
numbers would not be about this change. Conditions (1) and (2) must not be
measured here. They are blocked on the PointerWidth fix anyway, which is now
this PR's blocker for a third reason: condition (1), condition (2), and the
generated-artifact gate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…e earlier merge dropped 37e9712 took main's v1_compiler_emit_rust.rs because regeneration was blocked by the PointerWidth E0573. That dropped this branch's rendered SourceRootEvalDriver threading, and emit-build refused with E0061: native_test_context_absorb called with 3 arguments against 4. With the E0573 fixed on main (#12089/#12100), the regen round runs again. This installs ONLY this file from its candidate, which carries both main's emitter changes and this branch's file_alloc argument. The candidate also drifts in six other mirrors (compiler_tests, emitted_population, std_integer, std_machine_constraints, v1_compiler_infer_resolve, v1_rt). They are not this branch's: v1_rt's drift would delete a hand-carried content-hash change, and infer_resolve's would delete a declared transient bootstrap patch. They are left for their owners. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…g its figures (review 70540, DESIGN §6) Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
e691d4f was regenerated by a stale claim_executor (target/release rather than CARGO_TARGET_DIR), which omitted pub use of second, NonEmptyStr and literal_suffix. Regenerating with the current seed keeps them; the only remaining difference from main's mirror is this branch's driver threading. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
# Conflicts: # src/v1/stage0/src/v1_compiler_emit_rust.rs # src/v2/compiler/body_lowering_fold.dag # src/v2/workflow/floor_pure_producer_share.dag
…rtifact declares The floor refused 991d84b at frontier_ingestion_probe classify_source_in and classify_source: lex_walk_artifact declares source as v2.std.text String (FreeMonoid<Char>), and both sites passed the primitive String they hold (filesystem content, string literals). Latent on main: this branch changes an interface in body_lowering_fold that body_lowering_refusal_scope_test reads, and the floor planner (#12130) re-plans an untouched reader of a changed interface, which compiles this module for the first time since the mismatch entered. The fix is at the owning link: pass chars(s: source), the builtin every other lex_walk_artifact caller already uses (annotation_channel_test, namespace_graft_body_dissolution_witness_test). The callee's signature is unchanged and nothing is coerced. Both importers pass locally: normalize_retention_contract_probe_test 22/22, body_lowering_refusal_scope_test 9/9. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The merge of main (which carries #12132 and #11985, both touching the emitter) took main's pristine v1_compiler_emit_rust.rs; --required-regen then produced the candidate from the joined 05_emit_rust.dag and only that file was installed. A second regeneration round produced a byte-identical file (per-file fixed point, sha256 6297b8140753fc63). Main's regen round still refuses on #12011's release_locus_seed_constants_generated.rs; that belongs to the mirror-reconciliation lane and nothing is installed for it here. All nine Pkg15 witness arms green on the regenerated mirror. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Subject
A fatal diagnostic on the native compile path names its file and byte range. Before this change the specimen reported
FATAL AT <node locus, no file>— the cause was computed, carried, then unanchorable at the last boundary.Through the real CLI fold (
v2_cli_run→emit_compiler_import_closure_from_ingest_located), every link located:The distinct ranges are the point: interior links name their own authored spans, so this is real attribution rather than one span repeated.
Why this is two fixes, and why the brief's boundary was not sufficient
The brief (Pkg2b) named the
program_assemblycarry. Re-deriving the chain first (§6b) showed the carry is necessary but not sufficient — the measurement is what redirected the work:The fatal anchored on a node that was
OccurrenceSynthetic— no id at all — so a perfect span index would still have had no key. Naming the 12 nodes showed 11 built by sugar lowering and the namespace graft. That is Pkg11's boundary; the manager admitted the widened scope under stated conditions. The 2 remaining synthetics are producer marker atoms, left synthetic deliberately: they stand for no authored text.Implementation boundary
v2.std.nodenode_lowered_from— a lowered node keeps its source's occurrence. NotOccurrenceProjected, which is for a node minted in a different allocator with a scoped cause;std.occurrence_identitystates the case outright — "a carried-forward node gets no arm here".body_lowering_fold/namespace_graft— the type atom, fn-decl arrow and wrap, reified body, operator atom, parameter-list domain, and the module spine carry the authored node they lower. Every caller already held it, so the source is supplied, never searched for.02_parse—ParseArtifactcarries the allocator mark; seeded entry points. The unseeded doors are projections passingoccurrence_id_allocator_initial(), so ~86 existing call sites are byte-identical.program_assembly— the fold threads the allocator and merges per-file indices. The order is the design: merging without seeding is the silent-wrongness arm — two files both mint occurrence #N and file B's node resolves into file A.occurrence_identity_scope_lawalready named module-local reset a forbidden identity input.src/v1/05_emit_rust.dag— the EMITTED driver (side-chat finding). The renderedSourceRootEvalDrivercallednative_test_context_absorbwith 3 arguments against this branch's 4, and no.dagwitness builds that path, so the floor stayed green. Arity was the shallow half: that driver open-codes the per-file sequence so a clock can sit between phases, and it called the unseeded phases — so fixing only the arity would have compiled and been silently wrong, every file seeded from the same value, ids colliding on the one route that actually runs. New seam:program_assembly_phase_parse_measured_seeded,program_assembly_measured_alloc(returns the seed on a refused parse —allocator_initial()there would rewind the whole ingest at the first bad file), andprogram_assembly_allocator_next. The driver's per-file JSON now reportsoccurrence_seed/occurrence_nextso the hand-off is read off the built binary rather than argued. The template's own comment predicted this drift; it is the filed rowrealization_respells_a_modeled_folds_sequencing_to_instrument_it, and this is its first real receipt.00_compilenative_test_context_fold_step(review 69644) — the second whole-ingest fold, which called the unseeded door. Now seeded; the mark advances on every arm including refusing ones, since a read that refused still consumed the ids it minted. Not hypothetical:gunbc.compiler_frontend_program_statusjoins that route's refusals "to occurrence identity where an id is minted".IngestAssembly/CompilerClosureEmitLocated/ProgramAssemblySeededReadResult— the index rides beside the outcome, because a diagnostic needs its file exactly when the program did not assemble andOutcome'sRejectedarm carries no value. A refused assembly carries the spans of every file it parsed (review 69607).span_index_textual_locus_optional/lens_verdict_..._in_spans— the join is a lookup. Derived occurrences resolve through the recordedDerivedBychain. After Native diagnostics through the result boundary: the verdict carries the located chain, ambiguity names its lookup class and competing declarations #11965 merged, there is onematch d.at: the index-free door is a projection with an empty index, so the two cannot disagree.Positive control
v2.test.provenance.occurrence_file_attribution— supplied reads entering the real folds (tokenize, parse, normalize, graft, assembly andv2_cli_runall execute). 7/7 PASS:two_files_attribute_to_their_own_files_holds·two_files_mint_distinct_root_occurrences_holds·attributed_occurrence_carries_a_byte_range_holds·refused_assembly_still_locates_the_files_it_parsed_holds·cli_fatal_line_names_the_file_and_bytes_holds·cli_fatal_line_no_longer_reports_a_bare_occurrence_holds·native_route_threads_the_occurrence_mark_across_files_holdsThe two fixture modules are identical in shape on purpose — same productions, same order, so they mint the same ordinals as each other. That is what makes these discriminators rather than demonstrations. Roots are found by path, never list position.
Red mutation controls (executed)
Both CLI claims also FAIL under B. Each claim reds for its own reason; B leaving distinct-ids green is the measurement that these are not one claim written four times.
CI
Not yet re-run at this head (the merge of
origin/mainplus the emitted-driver fix). The figures below are fromaf7ba67339aand do not cover the emitter change.Floor read from its log, not the check status:
planned=417 executed=417 claims_failed=0 completed_over_cost_requirement=0,phases_failed=0. clippy / compiler / witnesses pass.An earlier head was refused
ENROLMENT-MARGIN-REFUSEDat 344ms against a 302ms margin. The lane's own discriminators were checked first — not a nested membership scan, not contention at constant eval steps. It was one front end rebuilt per claim, so the four shared producers are enrolled warm infloor_cross_claim_pure_producers_warmwith the portability argument that roster requires; none carries aResolutionContextor closure.No semantic movement
Occurrence identity is not an input to
content_hash(kind + edge labels + child hashes), so semantic hashes cannot move by construction. The fixed workloadv2.test.parse.expression_bodied_fn_decl_parseis 7/7 including bothsurvives_normalizeclaims and the refusal claim, and the whole floor is green at 417/417.Exact-head handback
b5e7aa16059(merge oforigin/main, which carries #11971, plus the emitted-driver fix). Interpreted evidence is fromaf7ba67339a. The built native CLI binary is not re-qualified here — that is an instrument run, and the.dagfold it emits from is what this PR changes; the specimen above is that fold executing, one layer above the binary.Disposition of what it replaces
assemble_program_from_ingestandemit_compiler_import_closure_from_ingestretained as projections of the located doors — one fold, no second path, no caller churn.lens_verdict_diagnostic_locus_textand..._located_chain_textare projections over an empty index; Native diagnostics through the result boundary: the verdict carries the located chain, ambiguity names its lookup class and competing declarations #11965'slens_verdict_node_occurrence_textremains the single answer for every unresolvable case and is called, not restated.fixtures/native_cli_door/door_probe.dag; nothing read it and the claim carries the source inline, so it was deleted (review 69628).Named remainder
A new ingest fold calling the unseeded door would reintroduce the collision, and no wall catches it — the annotation on
ParseArtifactsays so plainly rather than claiming otherwise. Making it unwritable needs a carrier distinguishing "a scope" from "a file", which is a larger modeling change and is not claimed here.The merge resolutions, with counts so they can be checked
v2.workflow.floor_pure_producer_shareis a roster, and both sides appended rows AND the notes justifying them — so either side alone drops the other's silently, and a notes block is easier to lose than a row because nobody counts prose. Resolved as a union: both note blocks kept, one declaration, six rows — this branch's four attribution producers (attribution_roots,attribution_refused_assembly,door_probe_cli_detail,native_route_roots) plus main'sbody_lowering_normalized_moduleandncr_outcomes. A roster conflict resolved without a stated member count is one nobody can check.src/v1/stage0/src/v1_compiler_emit_rust.rsismerge=generated-artifact, so the driver refuses rather than merging: it leaves the ours side in the worktree, marks the path unmerged, and prints the regeneration recipe. There are no conflict markers — that is what the driver guarantees on a refusal, so zero markers proves the driver worked and never that the content is right. Resolved by regenerating from the merged.dag(--regen-round-cost, twice as its own refusal requires), then verifying both authorities survived by symbol rather than by diff: main'semit_rust_demanded_host_bin_op,emit_native_freemonoid_matchandemit_rust_compile_error_expr, and this branch'soccurrence_seedthreading. Checking that both survived, rather than that the file changed, is what separates a regen that merged from one that overwrote.Two facts about this repo that this PR paid for, recorded so the next lane does not
compiler+clippygreen whilefloor+witnessesred is the SIGNATURE of a stale base — recognisable from the check list alone, before opening a log. The lanes inwitnesses.ymldisagree about what they check out, and the disagreement is the diagnostic:compileractions/checkout→ the merge ref, which already carries current mainclippyactions/checkout→ the merge reffloorref: ${{ github.event.pull_request.head.sha }}— step named "Checkout the commit this lane judges"witnessesneeds: [compiler, clippy, floor], the aggregator reflectingfloorThe floor lane judges the BRANCH HEAD, not the merge ref.
witnesses.yml's checkout step isref: ${{ github.event.pull_request.head.sha }}, and its name says so outright — "Checkout the commit this lane judges". So the usual reasoning that a PR run buildsrefs/pull/N/mergeand therefore already contains current main does not hold for this lane. A stale base reproduces in CI exactly as it does locally, however clean the merge ref is. Concretely, this PR went red ontest.claim.mtcollins1_census_image_local_wet.the_rendered_program_runs_and_its_output_parses_by_real_executionpurely because the branch lacked #12020 (host_capture_bind), which had been on main for an hour and a half. The instrument for a floor red on a long-lived branch is therefore a merge of current main — not a three-dot diff, which shows nothing for files main changed after the merge base and so reads clean on exactly the files that broke you.fixtures/native_cli_door/door_probe.dagis a path collision, not a resurrection. An earlier commit here deleted a file at that path — my own five-line orphan that nothing read (review 69628). Main has since landed a different, richer file at the same path from #11972, with real consumers ingunbc.instrument_targetsandv2.cli.compile_cli. Merging main brings it back, correctly. Same path, different artifact — this is the kind of thing that gets silently reverted by the next person who remembers only that it was deleted.The emitted driver: condition (1) built, condition (2) observed
(1) The emitted crate builds with warnings intact.
gunbc test //gunbc/instruments:self-hoston the composition:The threading was confirmed in the emitted
main.rs(let file_seed = context_state.alloc.clone(), then the seeded phase call), not inferred from a green build — a build that succeeds says the code compiles, not that the call is in it.(2) One occurrence sequence carries across the whole corpus, and across refusals. Whole-corpus
adjudicate, reading the driver's own per-file[native-context-split]rows:seed != prev next)next < seed(rewinds)The two arms discriminate against the driver's own refusal tally, over the whole population rather than a sample:
parse_g0_tokens_remain) — nothing recoverable, so the mark is handed offnext == seednext > seedThat exact match is the join: the handoff rows are the parse refusals, by identity, not by inspection.
On review 70027, named because it is worth having on the record: both findings were this PR stating a rule and then violating it — one of them (
span_index_textual_locus_optional's "a consumer re-deciding it would be a second authority") a rule this diff argues for in its own annotation, while minting a second authority for the occurrence-id projection two files away. The author is the person least able to see that, which is what review is for; a PR that carries both the rule and its violation on the record teaches the rule better than one that carries only the rule.The method, written down because the next person measuring over this corpus will want it: read the refusals by cause out of the driver's own
file_refusal_tallyrather than counting them yourself, then use that split as the two predicted arms. One population, two behaviours that must differ, both observed, neither sampled. A total refusal count would have proved nothing here — it is the split by cause that separates "minted nothing, hand off" from "minted, must advance".Continuation past a refused file, in the emitted loop:
The file after the refusal seeds at the refused file's
next, not at 0.The discriminating red, executed — not a counterfactual
Counters standing at zero read identically whether the property holds or the counter never fires, so the claim above was re-run with one line substituted in the throwaway tree:
program_assembly_measured_alloc's parse-refusal arm returnsoccurrence_id_allocator_initial()instead of the seed. Re-emitted, rebuilt, and adjudicated over the same corpus:seed != prev next)next < seed)next == seed)The same readable window, mutated:
One counter does not discriminate, and it has been renamed rather than left to be cited as coverage. The check formerly called sequence breaks stays 0 under a mutation that breaks the property outright. The reason decides what to do with it: a file's
seedis assigned from the predecessor'snextby the loop, so the comparison can only fire if the threading is broken, never if the threaded value is wrong — substitutingallocator_initial()leaves it silent because0is faithfully carried forward, and faithful carriage of a wrong value is exactly what it cannot see. It is not a weaker sibling of the other two; it checks a different proposition (the loop threads something) under a name that claimed the subject the other two actually establish, and an inert check keeping that name would be cited as coverage by anyone who did not read this table. It is now threading discontinuity, and it verifies carriage only; the value checks arerewindsandrestart at 0.Three independent measures of one mutation agree at identity grain, and that is the strength of the result — not any single row:
rewinds0 → 122 andrestart at 00 → 144, against the driver's own tally of 144 parse refusals.One mutation, three measures derived from different quantities, all landing on the same population count.
🤖 Generated with Claude Code