Skip to content

Conversation

ada4a
Copy link

@ada4a ada4a commented Sep 14, 2025

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?

@Urgau
Copy link
Member

Urgau commented Sep 14, 2025

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?

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.

@ada4a
Copy link
Author

ada4a commented Sep 21, 2025

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.

@Urgau
Copy link
Member

Urgau commented Sep 21, 2025

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).

Copy link
Member

@Urgau Urgau left a 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.

View changes since this review

Copy link
Member

@Urgau Urgau Sep 27, 2025

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.

Comment on lines -539 to +540
let diffs_and_inputs: Vec<_> = before
.into_iter()
.zip(after.into_iter())
let diffs_and_inputs: Vec<_> = iter::zip(before, after)
Copy link
Member

Choose a reason for hiding this comment

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

This is very pedantic 😄

Copy link
Author

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:
    left
        .iter()
        .enumerate()
        .zip(right.into_iter().map(|x| x + 2))
    Is imo much more understandable when written like this:
    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 explicit x.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..

Copy link
Member

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.

Comment on lines 385 to 408
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(),
Copy link
Member

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.

Copy link
Author

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...

Comment on lines -33 to +37
.map(|c| format!("- {}\n", c.sha))
.collect::<String>();
.fold(String::new(), |mut commits, c| {
_ = writeln!(commits, "- {}", c.sha);
commits
});
Copy link
Member

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.

Copy link
Author

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?

Copy link
Member

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.

Comment on lines -621 to +622
write!(f, "Unknown labels: {}", &self.labels.join(", "))
write!(f, "Unknown labels: {}", self.labels.iter().format(", "))
Copy link
Member

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.

Copy link
Author

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 {
Copy link
Member

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.

Copy link
Author

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 {
Copy link
Member

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 {
Copy link
Member

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,
Copy link
Member

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.

Comment on lines -13 to +14
pub fcp_start: Option<String>,
pub fcp_closed: bool,
pub start: Option<String>,
pub closed: bool,
Copy link
Member

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.

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.

2 participants