Stop the truncation doc asserting counts no test holds - #3233
Conversation
The comment stated 544, 34, 13 and 510 as facts. Two of them describe a state before the content trim existed, so the shipped detector cannot reproduce them at all; the other two moved when #3227 rewrote one of the members, within an hour of the comment being written. The live figure is KnownTruncatedRanges, which a test holds to the tree, so the comment points there and keeps only the ratio that carries the argument.
It said 31 member bodies, the current 31, and Thirteen stranding a literal, sitting on top of an array of 30. Recomputed against the shipped code rather than decremented: 30 in the swept trees, 12 stranding a literal. Both figures are removed rather than corrected. The array is asserted at set equality, so a numeral in the prose beside it is the one claim in the file nothing can fail on, which is the defect this file exists to report.
fc3c9fa to
75145fc
Compare
|
Reviewed. This is a doc-comment-only change in The rewrite itself checks out:
One observation, not a blocker since it's outside this diff: |
|
Reviewed. This is a comment-only change in Verified the specific claims:
No correctness, security, or performance concerns. LGTM. |
TheMemberScan_ReadsEveryDeclarationWhole's own summary said Thirteen members strand a literal today. Measured against the shipped code it is twelve, and today asserts currency, so a reader has no cue to read it as historical. The earlier sweep missed it because it was bounded by passages I authored, and this numeral sits in a paragraph I only partly edited. A sweep scoped by authorship cannot see a stale figure in a paragraph someone else wrote; re-swept by pattern over both whole files instead.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
Reviewed. This is a doc-comment-only change confined to two Darling test files (
🤖 Generated with Claude Code |
Most was false: twelve of thirty is a minority. Removing a numeral is not removing a claim, and a quantifier is worse in one way - nothing greps for a word, so Thirteen at least invited the suspicion that found it. The argument needs no quantity. A literal contained by nothing is labelled Unknown, which is only loud if some census looks for a site of that kind, and that holds for one entry or for all of them. Both occurrences now say the same thing and assert nothing that can rot, including the out-of-scope note that said a few.
|
Reviewed. This is a comment-only change confined to Verified the claims the PR makes:
No correctness, security, or performance issues found. LGTM. |
Both are the same defect as the truncation doc: a quantity in prose beside a population nothing asserts, wrong now and with no way to fail when it drifts. The where-clause count read nine; the scanned trees carry seventeen members with a constraint clause, plus a type-level one on a record. The block-comment count read six files; the corpus carries sixty with a `--` anywhere in a block comment, forty-eight on a non-asterisked continuation line -- the line a prefix filter actually misreads -- and thirty-eight once files whose only hits are CLI flags come out. That spread is the sharper point: the claim never said which corpus or which predicate, so it could not have been pinned even in principle, only removed. Both sentences keep their universal and lose only the tally, which is this file's own stated doctrine: a universal quantifier names the one counter-example that would break it, while a count only tells you to count again. Two other numerals in the file were checked and left. The tenth-bullet reference is held by the disposition map's equality assertion against CONTRIBUTING.md, so it cannot drift without reddening first. The 101 figure is explicitly dated to when it landed, scoped to a retired SKU outside the scanned trees, and labelled as evidence for a decision rather than a live figure.
|
Reviewed. This PR only touches XML/
No issues found. |
1 participant
ShapeOf's doc asserted four counts as facts: 544 ranges stopping short, 34 by more than one character, 13 stranding a string literal, and 510 losing only a semicolon.Two of them cannot be reproduced from the code they document. 544 and 510 were measured before
StatementEndtrimmed trailing;and whitespace. Run the shipped detector and you get neither number, so a reader checking the comment concludes the detector is broken rather than that the comment is old.The other two were already wrong when they merged. #3227 rewrote
ViewerDataService.Deadlock.cs LastTranStartedLocalontoFormatServerClock, into a shape the walk reads whole — so 34 became 33 and 13 became 12 about an hour after the sentence was written, from a PR that had nothing to do with this one. The same merge is why the shipped inventory is 30 rather than the 31 measured on the branch.The counts are removed rather than corrected.
TsqlConventionGuardTests.KnownTruncatedRangesis the live figure and a test holds it to the tree, so the comment points there instead. What stays is the ratio the argument actually needs — semicolon-only members outnumber the ones stranding real content by more than ten to one, which is why the trim exists — and it is stated as a ratio because that is what survives an edit to any one member.KnownTruncatedRanges' own doc carried the same defect and is fixed in the same change: it said "Editing 31 member bodies", "the current 31" and "Thirteen of these strand a string literal", sitting directly on top of an array of 30. Recomputed against the shipped code rather than decremented — 30 in the swept trees, 12 stranding a literal, so "Thirteen" was wrong independently of the total.That one is the sharpest instance: the array beside it is asserted at set equality, so the numeral in the prose is the one claim in the file that nothing can fail on. #3230's own argument is that a count "goes stale with no edit to any member" and belongs in a set — and the comment introducing that set violated it. Both figures are removed rather than corrected, and the comment now says why no count appears and tells the reader to count the entries.
Found by the CHANGELOG batch lane and github-03: the lane hit these numbers deciding what #3230's release note should say, and had to work out which of three disagreeing figures to believe. Both merged sources agreed on 31, which is why it did not look suspect.
Two more counts in the same file, found by review of this PR
A bot thread objected that the fix had replaced "Thirteen" with "Most of
KnownTruncatedRangesstrands a literal", and 12 of 30 is a minority. It was right, and it named a class the three prior sweeps over these two files could not see: a sweep for stale figures cannot find a stale quantifier, because a quantifier carries no numeral, no number-word and no currency word. Re-sweeping for quantifiers rather than digits found two more counts inTsqlConventionGuardTests.cs, both wrong, and one more bare quantifier.The generic-constraint comment said nine members in the scanned trees carry a where-clause. Seventeen do, plus a type-level constraint on the
SettingsObjectRead<T>record. The claim exists to argue the walker shape is worth arranging, so the wrong figure understated its own case.The comment-filter note said six files carry a
--inside block-comment prose. Sixty do with a--anywhere in a block comment, forty-eight on a non-asterisked continuation line — the line a prefix filter actually misreads, which is the scenario the note is about — and thirty-eight once files whose only hits are CLI flags come out. A second reader independently measured seventy, counting T-SQL block comments embedded in SQL literals as well; all fourteen of those extra matches sit inside verbatim@"..."strings, and on the words as written that reading is defensible too. They are also genuinely relevant to the guard — a--inside a T-SQL/* */must not be read as a line comment — just to its tokenizer rather than to its comment filter.That spread is the finding, more than any one of the numbers. Five defensible answers — 70, 60, 48, 38, and the tokenizer's own view — against a sentence that named neither corpus nor predicate. It could not have been pinned even in principle, and there is no reading under which it is six.
Both sentences keep their universal and lose only the tally, which is this file's own stated doctrine: a universal quantifier names the one counter-example that would break it, while a count only tells you to count again. Neither "12 of these" nor "A minority" was substituted, because both would be true today and stale on the next merge that rewrites a listed member — which is exactly what #3227 did to "Thirteen".
Two other numerals in the file were checked and deliberately left, since removing a correct, held count would be the opposite lesson. The tenth-bullet reference is held by the disposition map's equality assertion against
CONTRIBUTING.md, so it cannot drift without reddening first. The 101 figure is dated to when it landed, scoped to a retired SKU outside the scanned trees, and labelled as evidence for a past decision rather than a live figure.most/several/manyelsewhere in both files were read individually and are qualitative claims about general behaviour, not counts of a tracked set.CommentFilterAdoptionTestsalready holds prose counts against computed ones viaVerifySummaryCounts, non-vacuously in both directions. That is the right tool for a count that is derivable and stable; neither of these two is, which is why both are removed rather than pinned.CHANGELOG entry text
KnownTruncatedRangesis the live figure and a test holds it to the tree, so the comment points there and keeps only the ratio the argument needs. Review of the change found two more counts in the same file — nine where-clause members against seventeen, and six block-comment files against sixty — both removed the same way, and two correct held numerals left in place.