-
Notifications
You must be signed in to change notification settings - Fork 97
Run Clippy #2181
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
base: master
Are you sure you want to change the base?
Run Clippy #2181
Conversation
If you can split into smaller commits, that would be great. Not necessarily each lint into it's own commit, bundling multiple lints changes is fine. |
This is required for building `openssl-sys` on NixOS
Required for all the let-chains
clippy::{unused_lifetimes,elidable_lifetime_names}
clippy::{collapsible_match,unnested_or_patterns,match_same_arms}
takes up fewer lines
clippy::derivable_impls
clippy::{semicolon_if_nothing_returned,unnecessary_semicolon}
pointed out by `clippy::type_complexity`
clippy::{format_collect,format_push_string,useless_format}
much more concise
the `push` used to be conditional
clippy::{struct_field_names,upper_case_acronym}
I did try to group related lints, but there were many small commits left from lints that I couldn't find a good group for -- hopefully, having the lint name on those commits will at least make their intent clear. |
Thanks for splitting into many commits, that will help a lot. I will take a look at the PR in the next few weeks (I'm on vacation for the next two weeks). |
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.
This looks pretty good. Thanks for doing that.
Left some changes and a few nits.
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.
Could you remove the Nix changes from this PR, we are discussing those at #2179.
let diffs_and_inputs: Vec<_> = before | ||
.into_iter() | ||
.zip(after.into_iter()) | ||
let diffs_and_inputs: Vec<_> = iter::zip(before, after) |
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.
This is very pedantic 😄
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.
I must admit this one isn't even a Clippy lint, but rather a personal preference:
- I've often found the formatting of
.zip
to be suboptimal, where, especially when the to-be zipped iterators were built as a method chain of iterator adapters, they would get split up across many lines, making it hard to see what exactly we're zipping. For example, something like this:Is imo much more understandable when written like this:left .iter() .enumerate() .zip(right.into_iter().map(|x| x + 2))
iter::zip( left.iter().enumerate() right.into_iter().map(|x| x + 2) )
- And as shown in this particular case,
iter::zip
allows for replacing the explicitx.iter()
with&x
, and removing.into_iter()
entirely, which I also find pretty nice.
But again, this change in particular doesn't bring us closer to long-term goal behind this PR (have Clippy run as part of CI), so I could just remove it..
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.
I have no preference for either, so I'm fine with keeping your version.
let comment = format!( | ||
r#"> [!IMPORTANT] | ||
> This issue is *not meant to be used for technical discussion*. There is a **Zulip [stream]** for that. | ||
> Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed. | ||
<details> | ||
<summary>Concerns or objections can formally be registered here by adding a comment.</summary> | ||
<p> | ||
``` | ||
@rustbot concern reason-for-concern | ||
<description of the concern> | ||
``` | ||
Concerns can be lifted with: | ||
``` | ||
@rustbot resolve reason-for-concern | ||
``` | ||
See documentation at [https://forge.rust-lang.org](https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#what-kinds-of-comments-should-go-on-a-mcp-in-the-compiler-team-repo) | ||
</p> | ||
</details> | ||
{} | ||
[stream]: {topic_url}"#, | ||
r"> [!IMPORTANT] | ||
> This issue is *not meant to be used for technical discussion*. There is a **Zulip [stream]** for that. | ||
> Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed. | ||
<details> | ||
<summary>Concerns or objections can formally be registered here by adding a comment.</summary> | ||
<p> | ||
``` | ||
@rustbot concern reason-for-concern | ||
<description of the concern> | ||
``` | ||
Concerns can be lifted with: | ||
``` | ||
@rustbot resolve reason-for-concern | ||
``` | ||
See documentation at [https://forge.rust-lang.org](https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#what-kinds-of-comments-should-go-on-a-mcp-in-the-compiler-team-repo) | ||
</p> | ||
</details> | ||
{} | ||
[stream]: {topic_url}", | ||
config.open_extra_text.as_deref().unwrap_or_default(), |
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.
Is this actually the same thing? The other ones were not indented.
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.
Oh, no, sorry, that's an annoying bug in the Git merge driver that I'm co-developing – I really should get to fixing it...
.map(|c| format!("- {}\n", c.sha)) | ||
.collect::<String>(); | ||
.fold(String::new(), |mut commits, c| { | ||
_ = writeln!(commits, "- {}", c.sha); | ||
commits | ||
}); |
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.
Unsure about clippy::format_collect
, I'm not finding it particularly more readable compared to before, and it's not like this code is perf sensitive anyway.
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.
Yeah, you're right -- not to mention that clippy::format_collect
is pedantic
.
I could theoretically use Itertools::format_with
instead:
.format_with("\n", |c, f| f(&format_args!("- {}", c.sha)))
.to_string();
But it's also not the most readable imo. WDYT?
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.
Yeah, I also don't find it more readable IMO.
write!(f, "Unknown labels: {}", &self.labels.join(", ")) | ||
write!(f, "Unknown labels: {}", self.labels.iter().format(", ")) |
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.
Hum, I'm not finding this iter().format(...)
dance better than .join(...)
. I'm not sure it's worth it.
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.
Fair enough. I removed all the instances where the .iter()
/.into_iter()
was needed, leaving only those where we already were working with an iterator.
|
||
#[derive(Serialize, Deserialize, Debug, Clone)] | ||
pub struct FCP { | ||
pub struct Fcp { |
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.
FCP
is the correct name, it stands for Final Comment Period, it should not be lower-cased.
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.
I'm aware^^ This is from clippy::upper_case_acronyms
, which specifically targets acronyms
} | ||
#[derive(Serialize, Deserialize, Debug, Clone)] | ||
pub struct FCPIssue { | ||
pub struct FcpIssue { |
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.
Same here.
#[derive(Serialize, Deserialize, Debug, Clone)] | ||
pub struct FullFCP { | ||
pub fcp: FCP, | ||
pub struct FullFcp { |
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.
And here.
|
||
impl HtmlDiffPrinter<'_> { | ||
fn handle_hunk_line<'a>( | ||
&self, |
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.
Can we just allow clippy::unused_self
here, we may use &self
here in the future.
pub fcp_start: Option<String>, | ||
pub fcp_closed: bool, | ||
pub start: Option<String>, | ||
pub closed: bool, |
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.
Those field name changes needs to be reverted, the are coming from a API, they need to stay the same as the api.
For #1950
This turned out rather big... I'd like to make this easier to review, but I'm not sure how -- maybe split each lint's changes into its own commit?