fix(pdf): satisfy clippy::chunks_exact_to_as_chunks so CI is green again - #118
Merged
Conversation
Why this change was needed:
Rust 1.98 (2026-08-18) added clippy::chunks_exact_to_as_chunks, on by
default. It fires on pre-existing code in webclaw-pdf, and CI runs
`cargo clippy --all -- -D warnings` with dtolnay/rust-toolchain@stable, so
every job that lints now fails.
Nothing pushed to main between 2026-08-16 and the toolchain release, so no
run surfaced it until an external PR was re-checked. Since CI is now a
required status check on main, this blocked every open PR in the repo, none
of which had anything to do with PDF decoding.
Reproduced on unmodified main after `rustup update stable`:
warning: using `chunks_exact` with a constant chunk size
--> crates/webclaw-pdf/src/lib.rs:147:14
help: consider using `as_chunks` instead: `as_chunks::<2>().0.iter()`
What changed:
- The UTF-16BE branch of the PDF string decoder now uses `as_chunks::<2>()`,
which yields `[u8; 2]` directly. `u16::from_be_bytes` takes that array, so
the `[c[0], c[1]]` reconstruction and its bounds checks go away.
Behaviour is identical: `as_chunks` splits on the same boundary as
`chunks_exact` and discards the same trailing remainder, which for a
UTF-16BE payload is an odd trailing byte we were already dropping.
Problem solved:
`cargo clippy --all -- -D warnings` passes on rust 1.98. Verified with the
full CI set on 1.98: clippy, fmt, test --workspace, doc, and both wasm32
checks.
Note this raises the effective floor to a toolchain with `as_chunks`
stabilised. No crate declares rust-version, and CI always uses latest
stable, so nothing in-repo breaks; worth knowing if an MSRV is ever pinned.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CI on
mainis currently red, and it blocks every open PR.Rust 1.98 (2026-08-18) added
clippy::chunks_exact_to_as_chunks, on by default. It fires on pre-existing code inwebclaw-pdf, and CI runscargo clippy --all -- -D warningsagainstdtolnay/rust-toolchain@stable.Nothing pushed to
mainbetween 2026-08-16 and that release, so no run surfaced it until an external PR was re-checked. Because CI is now a required status check, this blocks PRs that have nothing to do with PDF decoding.Reproduced on unmodified main after
rustup update stable:The change
The UTF-16BE branch of the PDF string decoder now uses
as_chunks::<2>(), which yields[u8; 2]directly.u16::from_be_bytestakes that array, so the[c[0], c[1]]reconstruction and its bounds checks go away.Behaviour is identical:
as_chunkssplits on the same boundary aschunks_exactand discards the same trailing remainder, which for a UTF-16BE payload is an odd trailing byte already being dropped.Verified on rust 1.98
clippy --all -D warnings,fmt --check --all,test --workspace,doc --no-deps --workspace, and both wasm32 checks all pass.One note
This raises the effective floor to a toolchain with
as_chunksstabilised. No crate declaresrust-versionand CI always uses latest stable, so nothing in-repo breaks. Worth knowing if an MSRV is ever pinned.