Rust 1.97.1 + clippy clean (rebased onto master, gates re-verified) - #274
Conversation
Operator-directed: bump now, fix after. rust-toolchain.toml, the CI MSRV/BLAS_MSRV/matrix pins, and both Dockerfiles move together. The Dockerfiles were installing 1.94.0 - a pre-existing drift BEHIND this repo's own 1.95.0 pin, so the images were building on an older toolchain than the workspace declared. They are now on 1.97.1 with the rest. (The drift-proof pattern, worth adopting later: COPY rust-toolchain.toml and use --default-toolchain none, as ruff's Dockerfile does, so the image can never disagree with the pin.) Toolchain verified clean on the CURRENT dependency pins before this bump - measured on the sibling lance-graph workspace, which path-deps this crate, with no new lint or language surface on 1.97.1. Workspace clippy here has NOT been re-run under 1.97.1; that is the fix-after.
Owed fix-after of the toolchain bump. Six errors, all mechanical: - 3x clippy::question_mark in Iterator::next impls (indexes.rs:60, iterators/mod.rs:491 and :667) - a match returning None collapses to self.field.clone()?. - property_mask.rs:426 unusual_byte_groupings (0b11111_1000 -> 0b1_1111_1000), bitwise.rs:637 identity_op (+ 0 dropped, the breakdown kept as a comment), palette_codec.rs:810 needless_range_loop -> iter_mut().enumerate(). All three in #[cfg(test)] code. Nothing in src/simd_*.rs, no unsafe block touched, no public signature changed, nothing skipped. cargo fmt applied. HONESTY: the test suite was NOT run by the sweep - free disk crossed the 5 GB floor right after fmt and the worker stopped on its guard rather than pushing through (the correct call; the cause was a 9.8 GB sibling target dir, since cleared). Orchestrator runs the suite next. Worker tag-file: .claude/exec-runs/sonnet-197-lint-sweep.md
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughThe project updates its Rust toolchain from 1.95.0 to 1.97.1 across manifests, CI, Docker images, and local configuration. It also applies equivalent Clippy cleanups to iterator implementations and tests, with formatting and lint results documented. ChangesRust toolchain and lint cleanup
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: Poem
✨ Finishing Touches📝 Generate docstrings
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. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_7b9a5562-b58b-4492-93b7-8ac4335ebb07) |
`rust-toolchain.toml` moved to 1.97.1 and CI's `MSRV` / `BLAS_MSRV` env are already 1.97.1, but `Cargo.toml` still declared `rust-version = "1.95"` and the toolchain comment still described the 1.95 rationale. The bump was half-done. So the declared MSRV was one nothing verified: no CI job builds at 1.95. That is the same false-green shape as the feature-gated code this arc kept finding -- a claim with no run behind it. It matters off-repo. Consumers read `rust-version`, and tesseract-rs path-deps BOTH ndarray and lance-graph-contract; a 1.95 build of the contract crate still succeeds today, which is a coincidence holding at one commit, not a guarantee -- and precisely what an untested MSRV declaration buys. ndarray was also the last sibling still declaring 1.95 (lance-graph, OGAR, ruff, MedCare-rs, woa-rs, a2ui-rs, stockfish-rs are all on 1.97.1), so a consumer pulling two of them saw two different MSRVs. Both files now state 1.97/1.97.1 and the comment says they must move together.
What this does
Moves ndarray to Rust 1.97.1 and lands the clippy sweep the bump exposed.
ndarray was the last repo in the stack still pinned to 1.95.0 on
master.Two commits: the toolchain/CI/Dockerfile bump, and the lint sweep.
Rebased onto 41 newer commits, then RE-verified
This branch was 41 commits behind
master. Two things came out of that worthrecording:
1. The "6,511 deletions" were an artifact, not a diff. A
git diff origin/master..HEADon the stale branch showed everysrc/simd*.rsfile beingdeleted —
simd.rs,simd_avx2.rs,simd_avx512.rs,simd_neon.rs,simd_scalar.rs,simd_wasm.rs. That would gut the "all SIMD fromndarray::simd" invariant the whole stack depends on. It was purely the stalebranch point:
git ls-treeshows 17simd*files on master and 17 on HEAD.Nothing was deleted. Recording it because the diff is genuinely alarming to look
at and the next reader deserves the resolution, not the scare.
2. The sweep was re-verified AFTER the rebase, not before. The commit
message's "orchestrator-verified" was earned against the old master. 41
commits had landed since — the same setup that, in OGAR earlier today, brought
in code that had never been compiled under 1.97.1. Both gates were re-run on the
rebased tree:
cargo clippy --features approx,serde,rayon -- -D warnings→ 0 errorscargo clippy --features native -- -D warnings→ 0 errorsThese are the two invocations
.github/workflows/ci.yamlactually runs.The Dockerfile conflicts resolved toward master's prose (it had grown a
useful note about
rust-toolchain.tomldeliberately not being copied into theimage, which the bump commit had flattened away) with only the version strings
moved to 1.97.1.
One observation, not a claim
cargo clippy --all-featuresfails on stable with E0554 —#![feature]maynot be used on the stable channel — because
simd_nightlyis nightly-only byconstruction. That is not caused by these commits and not something CI hits
(no CI job uses
--all-features). Noting it so the next person who reaches for--all-featuresas a "stronger gate" knows why it cannot be one here.Summary by CodeRabbit
Maintenance
Code Quality