Repository navigation
Delete unrostered seed probes and orphan tests - #9160
Conversation
|
Reviewed as a deletion, which is where a rubber stamp does the most damage. I checked the one thing in this diff that DESIGN could plausibly be resting on, and the PR's own framing of it is correct. THE RECEIPT DELETION IS THE ONLY LOAD-BEARING QUESTION HERE, and it clears. DESIGN 4b cites the It survives for a reason the PR states and I verified independently rather than taking: the receipt has not executed since Rust tests left CI on 2026-07-11, so it was not evidence, it was a file that looked like evidence. That is the decoration case DESIGN calls worse than absent — a probe cited as coverage that cannot fail — and (4) protects evidence that stays enrolled and can still go red. This could not. Deleting it lowers no rung because the rung was never resting on anything that ran; what it does is make the gap visible, which is the honest state. I also checked the citation reach before agreeing, because the failure mode here would be leaving DESIGN pointing at a path that no longer exists — the section 3 stale-citation class landing in the canonical authority, which is precisely how this repo got the cite-the-symbol-not-the-position ruling. Measured on main: zero hits in DESIGN.md, zero across docs/, and exactly one in-tree reference outside the file itself, ONE THING I WANT ON THE RECORD, not a change request. After this lands, the forgery claim in 4b is a measurement with no in-tree instrument that can re-derive it — the same state the measurement-bankruptcy row declares for the emission board. That is not this PR's defect to fix, and re-homing it here would be the pre-emptive re-authoring the PR body correctly declines. But when someone next repairs the The rest is mechanical and checked: 16 binaries as the set difference against No changes requested. The — sent from smart-ram-730 |
…uted flag names an RcStr carrier that does not exist (#9212) * char_at's ascii-aware split has no producer on main: delete it and bound the ASCII test by pos `v1_rt::char_at_ascii_aware` / `string_length_ascii_aware` / `substring_ascii_aware` take a precomputed `is_ascii` flag, and their doc comment names the producer of that flag as "the `RcStr` carrier fact". No `RcStr` exists in this tree: `Value::Str` is `Rc<str>`, and every caller -- `char_at`, `string_length`, `substring`, and the one interpreter call site -- supplies `s.is_ascii()`, an O(n) whole-string rescan computed fresh per call. The split is therefore unroutable: it is three public functions whose parameter has no producer, plus a comment asserting a carrier that does not exist. Provenance, because the obvious reading (someone deleted RcStr) is wrong: b1775d8 (#8360) landed BOTH halves and is NOT an ancestor of main. main's history is rooted at 67437fc (#8833), a wholesale seed re-import whose tree already carries the runtime split (`src/v1/runtime_rust.dag` +826) beside an interpreter with no `RcStr` (+16717, zero occurrences). The flag has never had a producer anywhere in main's reachable history, and #8360's O(1) claim has never been true of this tree. The repair, at the single authority `src/v1/runtime_rust.dag` (mirrors `v1_rt.rs` / `v1_compiler_runtime_rust.rs` follow by regen): - Delete the `_ascii_aware` triplet. Nothing supplies a flag other than `s.is_ascii()`, so the parameter is a second representation of a fact the function can read itself (DESIGN §2/§3), and the comment on it is the §4b inflation case -- a carrier named for a rung the tree does not occupy. - Bound the ASCII test by the requested position instead of by the whole string. A leading run of ASCII bytes makes the byte offset equal the code-point offset, so `char_at` examines `bytes[..=pos]` and `substring` examines `bytes[..end]`, never the tail. Cost drops from O(n) + O(pos) to O(min(pos, n)) -- the fallback's own cost. Semantics are unchanged: where the old form fell back to `chars()` because the STRING contained a multibyte char, the new form takes the byte path only when the PREFIX up to the requested index is ASCII, which is exactly the condition under which byte index equals code-point index. - Route the interpreter's `native_len` `Value::Str` arm through `v1_rt::string_length` and fix its doc comment, which named the deleted helper. - Delete `gunbc.char_at_scaling_probe_support`. Its `DissolutionCondition` names `src/v1/stage0/src/bin/char_at_scaling_probe.rs`, deleted by #9160, and its trigger is "when char_at's O(1) property is floor-enrolled" -- a property this tree does not have. It is unconsumed (census row in docs/plans/unconsumed-module-residue-disposition.md) and its subject is gone. RESIDUAL, DECLARED RATHER THAN CLAIMED CLOSED: a left-to-right walk of a string is still O(n^2), now with a smaller constant rather than a different shape. A single call cannot be O(1) without the whole-string ASCII fact, which needs a carrier on the string value; that carrier -- or a cursor surface that does not re-index from zero -- is this class's next-rung trigger, and it is recorded in the `char_at` doc comment rather than left to be rediscovered. This change lowers no rung: the deleted split was inert, so nothing it guaranteed is lost. Evidence: dag/test/claim/char_at_unicode_witness_test.dag (SubstrateInputsOnly, floor-routed) gains the discriminating control for the prefix-bounded path -- "ab" + U+00E9 + "c" is 5 bytes and 4 code points, so a byte-offset implementation returns U+00A9 at index 3 and "c" at index 4 where code-point indexing returns "c" at 3 and "" at 4, with the same split applied to `substring`. * Regen: converge v1_compiler_runtime_rust.rs with the edited runtime_rust.dag authority (pass 1) Pass 1 of the stage0 two-pass convergence. `--required-regen` regenerated `v1_compiler_runtime_rust.rs` -- the stage0 transliteration of `src/v1/runtime_rust.dag` -- from the edited authority; this installs that candidate byte-for-byte. `v1_rt.rs` is emitted BY this mirror, so its pass-1 candidate was still the old `_ascii_aware` text and converges only on pass 2, after a rebuild against the mirror installed here. * Drop the substring assertion: its RED was never observed, so it is not coverage The witness gained three assertions for the prefix-bounded fast path. Two of them are demonstrated discriminating: with `char_at`'s prefix check removed and the binary rebuilt from scratch (perturbation confirmed present in source), `char_at_agrees_across_the_ascii_prefix_boundary`, `char_at_past_the_multibyte_char_is_not_a_byte_offset` and the pre-existing `char_at_indexes_code_points_on_multibyte_text` all go RED. The third, `substring_agrees_across_the_ascii_prefix_boundary`, does not. Its own perturbation -- `if bytes[..out_end].is_ascii()` replaced by `if true`, so the byte-slice path is taken unconditionally -- left it GREEN, twice, the second time with the binary deleted first, the build failure-checked rather than piped through `tail`, and the edit grep-proven in source. A follow-up probe that would have printed the returned values panicked in `cli_run.rs` on BOTH arms, so it measured nothing: identical output across arms is the signature of an instrument that did not run, not of agreement. So the mechanism is unexplained. What is NOT in doubt is the assertion's status: a check whose RED has never been observed is not evidence, and shipping it would put it in the worst class DESIGN §4b names -- permanently green as far as anyone can show, and cited as coverage precisely because it is named after the thing it does not test. It is removed rather than kept with a caveat, because a caveat in a PR body does not travel with the test. The `substring` code change stands: it is the same prefix-bounding as `char_at`, semantics-preserving by the same argument (the byte path is taken only when the prefix up to the requested index is ASCII, which is exactly when byte index equals code-point index), and substring is exercised heavily by the existing corpus. What it does not have is a discriminating control of its own, and the witness note now says so in the module rather than leaving a reader to infer coverage from the file's name. OPEN QUESTION, recorded rather than routed around: `substring(s, 0, 3)` on "ab" + U+00E9 + "c" under the unconditional byte path slices `s[0..3]`, which lands inside the two-byte U+00E9 and should panic on a non-char-boundary. It did not. Either that path is not reached by a named-argument `.dag` call, or the panic is absorbed somewhere between the interpreter arm and the claim runner's exit status. The second would be the more serious finding -- a witness that cannot go red because failures are swallowed would affect every witness, not this one -- and it is worth its own lane. --------- Co-authored-by: Brian Searls <briansearls1@gmail.com>
1 participant
Summary
src/v1/stage0/src/bin/*.rsminus the union declared bygunbc.ci_release_bins.dagdependents outside the seed-retention rosterseed_retention_frontier_rosterThis removes 4,216 lines without pre-emptively re-homing any behavior; replacements are authored only when a live consumer demands them.
Evidence standing
uri_scalar_forgery_receipt.rswas the executed evidence cited by the DESIGN §4b discussion of forgingsole_constructorvalues through an emitted mirror. Rust tests left CI on 2026-07-11, so this evidence had not executed in six weeks. Deleting it does not remove a working check; it makes the already-existing coverage gap visible.Verification
cargo check -p v1-compiler --all-targets(remote linux/amd64): passsrc/binbasename belongs toci_release_bins(the witness-declared list plusclaim_executorfrom the floor-invoked list)origin/mainafter the intervening merges: the pre-cut set difference remains exactly the same 16 binaries, and the same seven test files remain presentgit diff --check: passA targeted
claim_batchattempt reached corpus preparation but exited before evaluation because the invocation omitted its required explicit--function/--functions; it is not claimed as test evidence.Current CI standing
The failing run reached parse and regen successfully, then inherited main's
NonVerdictRowUnreachable count=127line-stop. Main has failed on that same population since #9095 landed; dedicated repairs are #9161 and #9169. The deletedexpected_red_roster_joinbinary is not the producer on this workflow path:claim_executorownswrite_expected_red_roster_join_tsv, and no workflow invokes the deleted standalone bin. This PR deliberately does not duplicate the unrelated 127-row repair.