fix(ci): rustc 1.98.0 added clippy::chunks_exact_to_as_chunks — sweep all 15 sites

[avrabe]

Unblocks every open PR. This is toolchain drift, not a code change.

What happened

The Clippy job uses an unpinned dtolnay/rust-toolchain@stable, and the GitHub runner's stable moved 1.97.1 → 1.98.0 partway through 2026-08-20. Proven from the runs' own logs:

run	time	rustc	Clippy
main @ 32c7e195 (the v0.58.0 release commit)	06:27Z	1.97.1	pass
a branch adding only a YAML file (#1011)	20:22Z	1.98.0	fail

1.98.0 introduced clippy::chunks_exact_to_as_chunks, which -D warnings promotes to a hard error. Every open PR reds until this lands.

CI reported one site. There were fifteen.

cargo clippy fails a crate on its first error and never reaches the rest, so the reported site is a lower bound, not the set — the same "first decline only" shape as scan_for_decline in the WCET model. The compiler enumerated the real set across three passes as each crate unblocked the next: 1 → 8 → 15, across synth-abi, synth-backend, synth-backend-riscv and seven synth-cli tests.

Fixed, not suppressed

slice::as_chunks stabilised in exactly 1.88.0 — read from the local std source's #[rustc_const_stable(feature = "slice_as_chunks", since = "1.88.0")], and 1.88 is this workspace's MSRV. So the idiomatic fix is available without an #[allow] or an MSRV bump. Four try_into().unwrap() calls disappear as a side effect, since as_chunks yields [u8; N] directly.

One subtlety, caught by the compiler

The closure rewrite differs between .map() and .filter(). After .iter(), map's closure receives &[u8; N], so |&c| binds [u8; N] correctly — but filter's receives &&[u8; N], so |&c| leaves a &[u8; N] and from_le_bytes rejects it. Three filter sites needed |&&c|.

A pattern that is right for one adapter and wrong for the neighbouring one is exactly what a local verification pass exists to catch. I could not have caught it locally at first: rustc 1.96.1 does not have this lint at all, so cargo clippy would have stayed silent whether the fix was right or wrong. I installed 1.98.0 to match CI and reproduced the failure before changing a line.

Gates — both toolchains, exit codes captured directly

rustc 1.98.0:  clippy 0   cargo test --workspace 0  (146 result blocks, 0 failed)
rustc 1.96.1:  clippy 0   (does not trade one break for another)
fmt --check 0  ·  claim_check 49/49  ·  model_coverage_audit --check 0

Byte-identity: frozen_codegen_bytes is in the passing suite, so the 10 anchors are unchanged. These sites decode bytes; they do not emit them.

Worth a follow-up, not fixed here

This is the second dtolnay/rust-toolchain break this session, from opposite causes: #984 bumped a pinned ref on the MC/DC job (where the ref is the compiler and the floors are counts over lowered wasm), and today an unpinned ref moved on its own under Clippy. The right answer differs per job — measurement jobs must pin, lint jobs arguably should float so new lints get caught — but a floating ref means a Rust release can red an unrelated PR at any moment, which is exactly what happened to a YAML-only change. A coherent float-vs-pin policy belongs alongside #965's dependency-hold enforcement in v0.59.

Refs #242.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!