Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: fix clippy lints from nightly-2025-03-16 #11273

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

conradludgate
Copy link
Contributor

I like to run nightly clippy every so often to make our future rust upgrades easier. Some notable changes:

  • Prefer next_back() over last(). Generic iterators will implement last() to run forward through the iterator until the end.

  • Prefer io::Error::other().

  • Use implicit returns

One case where I haven't dealt with the issues is the now more-sensitive "large enum variant" lint. I chose not to take any decisions around it here, and simply marked them as allow for now.

Comment on lines -874 to +875
&mut 0,
&mut size,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is due to a regression rust-lang/rust#138596

Copy link

7953 tests run: 7569 passed, 0 failed, 384 skipped (full report)


Flaky tests (3)

Postgres 17

Postgres 16

Code coverage* (full report)

  • functions: 32.3% (8733 of 27001 functions)
  • lines: 48.4% (74827 of 154632 lines)

* collected from Rust tests only


The comment gets automatically updated with the latest test results
62212f4 at 2025-03-17T10:43:58.839Z :recycle:

@conradludgate conradludgate changed the title conrad/clippy 2025 03 16 chore: fix clippy lints from nightly-2025-03-16 Mar 17, 2025
@@ -96,6 +96,7 @@ enum Message {

impl Message {
/// Convert proto message to internal message.
#[allow(clippy::result_large_err, reason = "TODO")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need these reason = fields? to me it seems they can be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added them to make it clear that I have not yet considered whether this allow is good or not

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants