-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Fix some clippy lints #138
Conversation
At that time, I was transitioning to the to the new implementation of the syntax tree, so that code churn rate was high enough for clippy & rustfmt being a significant problem. Overall, I am torn about this, curious what other folks think. Here are my rough thoughts about the issue. I definitely don't want to gate PRs on clippy and rustfmt: to me, additional per-PR code improvements that these tools bring feel much less important that annoyance and additional waiting time for the PR. I do want to use rustfmt and, to a lesser extend, clippy. These tools do improve code quality in minor-to-moderate ways. At the same time, I am not too keen on keeping a clean git history, especially since GitHub implemented the feature to get the previous blame. So applying suggestions manually from time to time seems fine by me. I am annoyed by some of the clippy suggestions, which make the code worse :) In particular:
I am also not thrilled by the idea of disabling clippy lints on a case-by-case bases. Is there perhaps some kind of conservative unopinionated clippy profile, that could be applied on the project level? |
I think we should enforce rustfmt in ci, but then just run clippy every so often if we find a good set of options. |
@DJMcNab why would be more useful than, say, running rusfmt once a week and adding
where fmt-changes is a command which applies rustfmt to changed files? I think it's a bad contributor experience when you PR fails just because you've forgotten a trailing comma, or use a different version of rustfmt. |
Different rustfmt version is a good point. I guess I've been spoiled by the ecosystem around nodejs, especially prettier combined with husky and vscode that I think of formatting as a non-issue. The Rust formatting ecosystem isn't quite there yet, unfortunately, so maybe it would be better to format every so often. I wonder if bors can handle rustfmting automatically somehow... |
You can (but shouldn't) make CI commit and push to the repo. Maybe someone could set up a bot that does fmt PRs? (Personally, I enforce a pinned stable rustfmt. I think it's better to require standard formatting always, which keeps git-blame accurate. The CI job is named so it's simple to see why it failed.) |
Definitely here you about some of the lints -- I've rebased this branch and only cherry-picked the Clippy lints that I think are probably unobjectionable.
I think so, but it looks like there's no way to configure it on a per-repo level and you need to add I think not-having clippy in CI and only doing it "once in a while" is probably a good choice until lints can be configured centrally and not per-crate. I think it's reasonable to do |
Because it's a stateful iterator, it's easier to explicitly clone it when necesary. Fixes clippy:clone_on_copy
Manually implement PartialEq
I guess we could also configure clippy through the command line:
seems to work fine. |
Don't have time for a thorough respose, but if that could make work via a script in
and that there's a test in |
@@ -88,7 +88,7 @@ pub struct ScopeEntry { | |||
} | |||
|
|||
impl ScopeEntry { | |||
fn new(pat: ast::BindPat) -> Option<ScopeEntry> { | |||
fn new_opt(pat: ast::BindPat) -> Option<ScopeEntry> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use new
to name such methods? It's what stdlib does, so it looks like a bug in clippy:
https://doc.rust-lang.org/std/ffi/struct.CString.html#method.new
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this will be fixed with rust-lang/rust-clippy#3338
crates/ra_analysis/src/job.rs
Outdated
@@ -11,7 +11,7 @@ pub struct JobToken { | |||
} | |||
|
|||
impl JobHandle { | |||
pub fn new() -> (JobHandle, JobToken) { | |||
pub fn new_pair() -> (JobHandle, JobToken) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree that new
probably isn't the best name here, the whole JobHandle
infra will be removed once we finish migration to salsa.
This reverts commit 2ae9dfa.
bors r+ Thanks! |
138: Fix some clippy lints r=matklad a=alanhdu I went ahead and fixed all the clippy lints (there were a couple I thought would be better unfixed and added `cfg` statements to allow them) and also re-enabled clippy and rustfmt in CI. They were disabled with `no time to explain, disable clippy checks`, so hopefully this won't go against whatever the reason at the time was 😆. One question about the CI though: right now, it's an allowed failure that runs against the latest nightly each time. Would it be better to pin it to a specific nightly (or use the `beta` versions) to lower the churn? Co-authored-by: Alan Du <[email protected]>
Build succeeded |
Filed #155 for rustfmt |
I went ahead and fixed all the clippy lints (there were a couple I thought would be better unfixed and added
cfg
statements to allow them) and also re-enabled clippy and rustfmt in CI.They were disabled with
no time to explain, disable clippy checks
, so hopefully this won't go against whatever the reason at the time was 😆.One question about the CI though: right now, it's an allowed failure that runs against the latest nightly each time. Would it be better to pin it to a specific nightly (or use the
beta
versions) to lower the churn?