fix(stdlib): use as_chunks in hex_to_bytes to unbreak clippy on Rust 1.98

[logbie]

Summary

The nightly build and CI on main are both red. This is a one-line fix for a single new clippy lint.

Root cause: toolchain drift, not a code regression. Rust 1.98.0 shipped on 2026-08-18 and promoted clippy::chunks_exact_to_as_chunks into the default lint set. Both CI lanes pin dtolnay/rust-toolchain@stable and run clippy with -D warnings, so the single chunks_exact(2) call in src/stdlib/crypto.rs (hex_to_bytes) turned into a hard compile error the moment either lane next ran.

Failing runs:

• Nightly Build 33235732094 — Build WFL for Windows failed at step 8 Run clippy after 93s; Create or Update Nightly Release skipped, so no nightly artifacts were published for 2026-08-29.
• CI 33173832824 (push to main) and 33173861966 — Build, Test, Clippy failed at Run Clippy, same lint.

error: using `chunks_exact` with a constant chunk size
    --> src/stdlib/crypto.rs:1049:10
     = note: `-D clippy::chunks-exact-to-as-chunks` implied by `-D warnings`

Why it surfaced only now

main did not move between 2026-08-14 and 2026-08-28. Every scheduled nightly in that window took the designed should_build=false no-change skip, so clippy did not actually execute against the tree after Rust 1.98 landed on 08-18. Merging #718 on 08-28 was simply the first thing to exercise the lint. The repo read green for ten days while already being broken — worth a look separately from this PR (see below).

What changed

src/stdlib/crypto.rs only — chunks_exact(2) → as_chunks::<2>().0.iter(), plus a comment explaining why discarding the remainder half is sound.

No behaviour change. The is_multiple_of(2) guard directly above already rejects odd-length input, so as_chunks::<2>()'s remainder is always empty and discarding it drops nothing. Each pair now arrives as &[u8; 2] rather than a runtime-length slice — decoding stays byte-oriented, so the multi-byte-safety property the doc comment describes is untouched.

slice::as_chunks is stable since 1.88.0, comfortably under the crate's rust-version = "1.94" MSRV (verified against the 1.98.0 stdlib source, not from memory).

Verification

Run locally on rustc 1.98.0 (88d9e12ae 2026-08-18) — the same toolchain @stable resolves to in CI. Reproduced the failure first, then confirmed the fix:

Check	Result
cargo clippy --lib -- -D warnings (pre-fix)	reproduced the exact CI error
cargo clippy --all-targets --all-features -- -D warnings	exit 0 — matches the ci.yml gate verbatim
cargo fmt --all -- --check	clean
cargo test --lib	690 passed, 0 failed, 6 ignored

Because hex_to_bytes decodes untrusted key material, I also proved the two implementations are observably identical rather than assuming it: a differential harness compared old vs. new over 18,327 inputs — every valid 1- and 2-byte UTF-8 string, plus multi-byte characters (é, 日本, a日), odd lengths, empty input, non-hex bytes, embedded NULs, and 64-byte keys. Zero mismatches.

Per testing.md §risk classes this is R0 CI mechanics: the existing clippy gate is the failing-first test, so no manufactured Red→Green test is included. The differential harness was verification scaffolding and is deliberately not committed.

Not fixed here, worth deciding

A no-change nightly skip means a toolchain-drift break stays invisible until someone merges. A cheap mitigation would be having the nightly still run fmt/clippy/test when should_build=false, and only skip the expensive packaging and release steps — that would have caught this on 08-19 instead of 08-29. Happy to open that separately if you want it; I did not bundle a workflow change into a lint fix.

---

Posted by the WFL repo warden (automated triage pass). I do not merge — this needs a human.

---

Summary by CodeRabbit

• Bug Fixes
  • Improved the reliability of hexadecimal string decoding while preserving existing behavior.
  • Added validation to ensure hexadecimal input has an even number of characters.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-08-29T05:58:16.513974Z	9896884	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: fea89fa1-16a7-4dd9-bd4f-f07d9b5b9275

📥 Commits

Reviewing files that changed from the base of the PR and between 1d1fef6 and 9896884.

📒 Files selected for processing (1)

• src/stdlib/crypto.rs

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

hex_to_bytes now uses fixed-size two-byte chunks after validating that the input length is even. Hex decoding behavior remains unchanged.

Changes

Crypto decoding

Layer / File(s)	Summary
Use fixed-size hex pairs src/stdlib/crypto.rs	hex_to_bytes replaces chunks_exact(2) with as_chunks::<2>(). The existing even-length check remains in place.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Merge Risk: ⚪ Minimal · up to 98968

This localized change updates hex decoding to satisfy the newer Clippy lint without changing behavior; the existing validation remains in place and the relevant checks pass. No actionable merge-blocking risk remains after normal checks and review.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the main change: replacing the hex decoder's chunking method with as_chunks to resolve a Clippy failure on Rust 1.98.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch warden/fix-clippy-chunks-exact

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[Copilot]

Pull request overview

This PR fixes a new Clippy lint failure on Rust 1.98 by updating hex_to_bytes in the stdlib crypto module to use slice::as_chunks::<2>() instead of chunks_exact(2), keeping behavior the same while satisfying the newer lint.

Changes:

• Replace chunks_exact(2) with as_chunks::<2>().0.iter() in hex_to_bytes.
• Add an inline comment explaining why discarding the remainder from as_chunks is sound given the existing even-length guard.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[logbie]

CI has settled on this branch: 19 pass, 1 skip (Bump Version), 0 failures — MERGEABLE/CLEAN.

The check that matters is Build, Test, Clippy, which passed in 7m34s on the same runner and toolchain that failed it on main. Both Integration lanes and both Run WFL Programs lanes are green on Windows and Linux.

One caveat worth stating plainly rather than glossing: PR CI runs clippy on Ubuntu only (the long-standing structural gap — Windows clippy executes solely in the nightly), so the Windows clippy step that actually broke run 33235732094 is not directly re-proven here. I consider the risk negligible — the lint fires on plain chunks_exact in shared, non-cfg-gated code, and I reproduced and cleared it locally on rustc 1.98.0, the exact toolchain the Windows job resolves — but the real confirmation is the first nightly after this merges.

Merging this should also turn PR #717 green (its red is the same inherited lint) and restore a trustworthy rollup on #716.

Posted by the WFL repo warden (automated triage pass).

[logbie]

Follow-up automated pass (09:0x UTC) — I went back and bounded the Windows-clippy caveat I flagged on this PR earlier, and the news is good for merging.

The nightly's Windows clippy hit exactly one lint, and it is the one this PR fixes.

Pulling the full job log for the failed nightly (run 33235732094, job 99056300613, Build WFL for Windows), the Run clippy step ends with:

error: using `chunks_exact` with a constant chunk size
  --> src\stdlib\crypto.rs:1049:10
error: could not compile `wfl` (lib) due to 1 previous error
error: could not compile `wfl` (lib test) due to 1 previous error

due to **1** previous error on both units is the load-bearing detail: rustc emits every lint diagnostic for a crate before aborting, so that count is a total, not a first-hit. Across all 21 cfg(windows) / cfg(not(unix)) sites in src/, crypto.rs:1049 was the only Rust 1.98 violation. Nothing else is hiding behind it.

What the log does not prove, stated plainly: because the lib failed, clippy never reached the wfl bin target, the integration tests, or wfl-lsp. So the honest residual scope after this merges is src/main.rs:531 plus the ~40 cfg(windows) sites under tests/. I looked at all of them, and the risk there is very low — they are almost entirely WFL programs inside r#"..."# string literals plus flat Command::new("cmd.exe").args([...]) and assert! calls. There is essentially no Rust idiom surface (no slice chunking, no iterator adapters, no numeric casts) for a new lint to land on. wfl-lsp has zero cfg(windows) sites. And chunks_exact now appears nowhere in the tree outside the comment in this diff, so this lint specifically cannot recur.

Verification note: the sandbox toolchain used to check this is rustc 1.98.0 (88d9e12ae 2026-08-18) — byte-identical to the one the nightly installed — but it is Linux/aarch64, so I could not execute a real Windows clippy run locally (no MSVC, and ring/sqlx rule out a cross-target check). The bound above comes from the CI log itself rather than a local Windows run; I would rather say that than imply coverage I do not have.

Net: this PR is green (18 pass / 2 skip / 0 fail), MERGEABLE/CLEAN, and is the single thing standing between main and a green nightly — tonight's 05:15Z run will fail the same way if it is not merged. Worth watching the first nightly after the merge rather than assuming green, since it will be the first time since Rust 1.98 landed that clippy gets past the lib on Windows.

Posted by the WFL repo warden (automated triage pass).