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

internal: fix most Clippy lints #16398

Merged
merged 4 commits into from
Jan 19, 2024
Merged

Conversation

Urhengulas
Copy link
Contributor

This PR is the result of running cargo clippy --fix && cargo fmt in the root of the repository. I did not manually review all the changes, but just skimmed through a few of them. The tests still pass, so it seems fine.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 18, 2024
@Urhengulas Urhengulas marked this pull request as draft January 18, 2024 13:08
@Urhengulas
Copy link
Contributor Author

The tests fail in CI, but not locally 🤔

@lnicola
Copy link
Member

lnicola commented Jan 18, 2024

ASSERT_MAX_FILE_ID_IS_SAME looks pretty gnarly, I'm not surprised Clippy got confused.

@lnicola
Copy link
Member

lnicola commented Jan 18, 2024

I also see some new warnings:

image

@Urhengulas
Copy link
Contributor Author

I also see some new warnings:

I am on it

Comment on lines 399 to 411
let Some(expn) = db.lookup_intern_syntax_context(span.ctx).outer_expn else {
return false;
};
let expn = db.lookup_intern_macro_call(expn);
// FIXME: Record allow_internal_unstable in the macro def (not been done yet because it
// would consume quite a bit extra memory for all call locs...)
// if let Some(features) = expn.def.allow_internal_unstable {
// if features.iter().any(|&f| f == sym::edition_panic) {
// span = expn.call_site;
// continue;
// }
// }
expn.def.edition >= Edition::Edition2021
Copy link
Member

Choose a reason for hiding this comment

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

Please undo this again, this is a loop because of the commented out code and so has meaning once thats fixed again

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure

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've reset the branch to not include the manual changes. They will come in a separate PR.

@@ -86,6 +86,7 @@ impl Pool {
self.job_sender.send(job).unwrap();
}

#[allow(clippy::len_without_is_empty)]
Copy link
Member

Choose a reason for hiding this comment

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

And this is why we don't really run clippy on the code base 😅 the defaults are sometimes questionable

Copy link
Member

Choose a reason for hiding this comment

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

It's not Clippy's fault, I'd expect len to return either the thread count or the pending queue size, not the number of running jobs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And this is why we don't really run clippy on the code base 😅 the defaults are sometimes questionable

We can configure it. But I feel it is useful to catch a lot of small cleanups, which I believe is useful.

Copy link
Member

Choose a reason for hiding this comment

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

Overall yes, I do want us to run clippy. I just don't like some of the default set of lints it has. Related #15918

@@ -28,6 +28,7 @@ impl<T> NonEmptyVec<T> {
}

#[inline]
#[allow(clippy::len_without_is_empty)]
Copy link
Member

Choose a reason for hiding this comment

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

This could arguably return NonZeroUsize, but I don't know if it silences the Clippy warning. Anyway, it's not even used, so..

@Urhengulas Urhengulas marked this pull request as ready for review January 18, 2024 16:32
@Veykril
Copy link
Member

Veykril commented Jan 19, 2024

@bors r+

@bors
Copy link
Contributor

bors commented Jan 19, 2024

📌 Commit 255cde7 has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Jan 19, 2024

⌛ Testing commit 255cde7 with merge 85c9a83...

@bors
Copy link
Contributor

bors commented Jan 19, 2024

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 85c9a83 to master...

@bors bors merged commit 85c9a83 into rust-lang:master Jan 19, 2024
19 checks passed
@Urhengulas Urhengulas deleted the satisfy-clippy branch January 19, 2024 10:26
@lnicola lnicola changed the title cargo clippy --fix internal: fix most Clippy lints Jan 20, 2024
@ivan
Copy link
Contributor

ivan commented Jan 25, 2024

https://github.com/rust-lang/rust-analyzer/pull/16398/files#diff-fa039ab572a8591c57be2cea529bb1e287b071b8f30cd5d495da3df98d2a31d1L191-L193 match was removed here in fn match_pattern(), but I think this test was specifically testing match patterns.

@lnicola
Copy link
Member

lnicola commented Jan 25, 2024

Looks like some of the other tests in there might be affected too.

@Veykril
Copy link
Member

Veykril commented Jan 25, 2024

Oh, that should definitely be reverted. Forgot we had these weird tests there

@Urhengulas
Copy link
Contributor Author

@ivan thank you for spotting, created an issue for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants