80 findings, not the 14 the first run showed -- clippy stops at the first
failing compilation unit, so `--keep-going` is what makes the list complete.
60 were machine-applicable (`cargo clippy --fix`). The rest by hand:
* five descending `sort_by` -> `sort_by_key(Reverse(..))`
* `chunks_exact(4)` on both sides of four zips, so the compared items stay
`[u8; 4]` rather than one array against one slice
* three `type` aliases for the census maps and the captured-quad tuple
* `&PathBuf` -> `&Path` in two disc tests
* two range loops; one of them keeps `#[allow(needless_range_loop)]` with the
reason -- the index is into a map's value, which changes each iteration
* the module doc list in `invert_capture` re-indented to markdown's rules
* `blit`'s eight arguments get `#[allow(too_many_arguments)]`, not a struct
One dead `let off = b.len();` in a `ratc` test is dropped rather than renamed.
The sibling test at :162 is the one that asserts an offset; if this one was
meant to as well, that is a test change and not a lint fix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
sylpheed-port reconciled the population gap exactly and I reproduced it: filtering
max_t > 0 gives 1781 records and 92.3 %, their figures precisely. Same numerator,
1643, both ways.
My stated explanation was wrong. I said the scan requires a timed keyframe; it does
not, because .max() returns Some(0) rather than None for records whose keyframes are
all at time 0, so 1530 records where the question has no content stayed in my
denominator and counted as failures by construction.
The conclusion is untouched -- +0x04 is 0 % under either denominator.
Records their diagnosis of why it stayed invisible: the numerator agreed to the
unit, so a shared 1643 read as agreement and neither of us looked there. And both
halves needed a qualifier neither carried -- 92.3 % is of the records where the
question is meaningful, not of nested records.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
sylpheed-port aimed my own boundary finding at my loop-length control. Reproduced
from my reader over every pak: +0x04 has 0 violations too, so the falsifier rejects
+0x0c and accepts +0x04 and never discriminated. What identifies +0x08 is the
exactness statistic the page presents as secondary -- exact match in half the
records against 0 % for +0x04.
Population differs from theirs, 3311 records against 1781, because this scan takes
every pak and requires a timed keyframe, so the percentage moves but the
discrimination does not.
Second time this week with the weight on the wrong leg: a count taking credit for an
exclusion argument, now a falsifier taking credit for an exactness statistic, and
both times the real discriminator sat beside it described as a formality.
Their general form is sharper than my boundary rule: an interior consistency check
is satisfied by any internally consistent reading, and that is what a wrong offset
into a regular structure usually is.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
