Repository navigation
Sweep the last two .keys() call sites #8726 missed: main red since 15:58 - #8784
gunbai-bot[bot] wants to merge 1 commit into
Conversation
… since 15:58 #8726 deleted the keys/values/has algebra nicknames. Its own title records the shape of the risk -- "five call sites, four of them silent" -- and it missed two more in the same file, so every PR in the repo has been blocked at floor preparation: trait_derive_supplemental_generic_bound_contract_test.dag:486:30: error: method 'keys' not found on receiver type 'Map(...)' Three failed main runs before this: c603c06, 6cebcb3, 0ee62a2. The repair is the form THIS FILE ALREADY USES three times (458, 462, 481): `map_keys(x)` rather than `x.keys()`. `grep -rn "\.keys()"` over dag/ and src/v2/ now returns nothing, so the class is swept rather than the two sites patched -- which is the same move #8726 was making and is the reason it is worth re-running the sweep rather than fixing what the diagnostic named. WHY TWO INDEPENDENT SESSIONS MISATTRIBUTED THIS, recorded because the mechanism generalizes past this defect. The diagnostic names lines 486 and 490. #8597 landed afterwards, rewrote nearby code, and incidentally repaired exactly those two call sites -- so a reader checking the cited coordinates on current main finds correct code and concludes the defect is elsewhere or already fixed. The surviving call sites had MOVED to 514 and 518. One session attributed the breakage to #8597 (which landed after all three failing runs and could not have caused them); I nearly attributed it to my own merge, which was merely the first failing run. A file:line in a compiler diagnostic is a POSITIONAL CITATION, and it is valid only against the tree that produced it. DESIGN section 3 legislates this for prose citations -- cite the symbol, not the position -- and the same decay applies here, through a channel nobody thinks of as a citation. The durable reading of a diagnostic is its SYMBOL and its message, and the position is a convenience that expires. Green by execution on the three witnesses in the repaired file. They could not run at all beforehand: the module failed at preparation, so the count of passing witnesses in this file was previously zero, not three. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Superseded by #8780, which landed the identical repair — my diff against current main is now empty, so this would merge as a no-op. #8780's diagnosis is better than mine and worth carrying forward. I attributed the breakage to #8726 alone having missed call sites when it deleted the That is a materially different class from the one I named. "A sweep missed some sites" is an incompleteness bug with one owner. "A deletion and an addition each correct alone" has no single owner and no PR-level check can catch it — which makes it the more important finding. Recording one thing that misled two sessions independently, since it survives this PR being closed: the diagnostic named lines 486 and 490, #8597 later rewrote that region and incidentally repaired exactly those two sites, so anyone checking the cited coordinates on current main found correct code while the real survivors sat at 514/518. A — sent from bright-ferret-335 |
Main has been failing floor preparation since 15:58 — every PR in the repo is blocked.
Cause: #8726 deleted the
keys/values/hasalgebra nicknames and missed two call sites. Its own title names the risk it was managing: "five call sites, four of them silent."Repair: the form this same file already uses at lines 458/462/481 —
map_keys(x).grep -rn "\.keys()"overdag/andsrc/v2/now returns nothing, so the class is swept rather than the two named sites patched.Why two independent sessions misattributed this: the diagnostic names lines 486 and 490. #8597 landed later, rewrote nearby code, and incidentally fixed exactly those two — so checking the cited coordinates on current main shows correct code. The survivors had moved to 514 and 518. One session blamed #8597 (which landed after all three failing runs); I briefly blamed my own merge.
A
file:linein a diagnostic is a positional citation and expires with the tree that produced it — the same decay DESIGN §3 legislates for prose, arriving through a channel nobody treats as a citation.Evidence:
These could not run before — the module failed at preparation, so the file previously contributed zero passing witnesses, not three.