fix(formats): collapse the one else { if }, so both toolchains agree
Some checks failed
CI / Native — linux (pull_request) Successful in 55m56s
CI / WASM — Web (pull_request) Failing after 12m9s
CI / Formatting (pull_request) Failing after 2m8s

`ascii_runs` in movie_manifest.rs had a nested `else { if .. }`. Clippy's
`collapsible_else_if` flags it — on some toolchains.

WHY IT WAS NEVER CAUGHT, AND WHY THAT IS THE INTERESTING PART:

  clippy::collapsible-else-if   @1.92.0 (2025-12-08)  ->  warn
  clippy::collapsible-else-if   @1.98.1 (2026-09-01)  ->  allow

CI installs `dtolnay/rust-toolchain@stable`, which floats. The runner is on
1.98.1, where this lint is allow-by-default, so the Clippy job passed. A local
run on a nine-month-old stable failed on the same bytes. Neither instrument was
broken; "clippy clean" is simply a statement about a toolchain and a date, and
nothing in the pipeline records which. That is #15, and this commit does not fix
it -- it removes one instance of its consequence.

Fixing it rather than pinning, because `else { if }` is worse code on every
version. A tree whose cleanliness is contingent on a release date is the thing
to avoid; agreeing with both toolchains is cheaper than arguing about which one
is right.

⚠️ I FIRST DIAGNOSED THIS WRONG, and the wrong version is worth recording. From
CI's rustfmt reporting 774 hunks and mine reporting 774, I concluded the
toolchains matched, therefore the clippys matched, therefore CI's green must be
a cached or ungated result -- "the frozen splash again". Every step after the
first was false. rustfmt is deliberately output-stable within a style edition;
clippy explicitly moves lints between groups. Measured here afterwards:

  rustfmt 1.8.0-stable -> 774 hunks
  rustfmt 1.9.0-stable -> 774 hunks     (nine months apart, identical)

So formatting parity carries no information about which clippy ran. It is the
same error as reading protection off a settings page or reachability off a DNS
record: a property inferred from something ADJACENT to it. The peer refuted it
by measurement -- `No cache found` in the run log, and `success()` evaluating
'true' in 207 against 'false' in 203 -- rather than by accepting the framing.

Verified on both: 1.92.0 `clippy --workspace -- -D warnings` rc=0 (was 101);
1.98.1 with the lint forced on, 0 sites. rustfmt still 774, so no debt added to
#12. Tests 207 passed / 0 failed / 14 ignored, unchanged.
This commit is contained in:
MechaCat02
2026-09-06 10:17:55 +02:00
parent e56c1228ac
commit d8807c4f8f

View File

@@ -339,12 +339,10 @@ fn ascii_runs(bytes: &[u8], min: usize) -> Vec<String> {
for &b in bytes {
if (0x20..=0x7e).contains(&b) {
cur.push(b as char);
} else if cur.len() >= min {
out.push(std::mem::take(&mut cur));
} else {
if cur.len() >= min {
out.push(std::mem::take(&mut cur));
} else {
cur.clear();
}
cur.clear();
}
}
if cur.len() >= min {