Drop the lint expectations clippy 1.98 no longer fulfils - #8564
Conversation
`clippy::std_instead_of_core` stopped firing at the four places that carry an `#[expect]` for it. All four were added for the same false positive, on items whose `core` counterpart is still unstable. `unfulfilled_lint_expectations` is denied through `-D warnings`, so the three clippy jobs and the WASM check fail on current stable for every pull request, whatever it touches. Assisted-by: Claude Code:claude-opus-5
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
💤 Files with no reviewable changes (4)
Included review availability: Your plan provides up to 10 included reviews per hour; 9 remain after this review. 📝 WalkthroughWalkthroughThe change removes ChangesClippy expectation cleanup
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This localized cleanup removes obsolete lint expectations without changing runtime behavior; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
Thank you! |
Summary
The three clippy jobs and the WASM check fail on current stable for any pull request, whatever it touches:
clippy::std_instead_of_coreno longer fires at four of the places that carry an#[expect]for it, all four written for the same false positive on items whosecorecounterpart is still unstable. Once the lint stops firing,unfulfilled_lint_expectationsturns each of those attributes into an error under-D warnings, and the crate fails to check.Removing the four is enough. The other two
#[expect(clippy::std_instead_of_core)]in the tree, incrates/host_env/src/posix.rsandcrates/vm/src/stdlib/_signal.rs, still fire, so they stay.Test Plan
rustc 1.98.0 (88d9e12ae 2026-08-18) in a Debian container.
The command CI runs, with the same flags:
finishes clean here. Without the change it stops at
crates/host_env/src/fileutils.rs:449, then atcrates/vm/src/stdlib/_io.rs:117, then atcrates/stdlib/src/pyexpat.rs:4andcrates/stdlib/src/ssl.rs:17. The same four jobs are red on #8561, #8562 and #8563 for the first of those.Also run:
cargo fmt --check, clean, andcargo test --workspace --exclude rustpython_wasm --exclude rustpython-venvlauncher --exclude rustpython-capi, 41 test binaries and no failures.Summary by CodeRabbit