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

clippy #740

Merged
merged 2 commits into from
Jan 9, 2024
Merged

clippy #740

merged 2 commits into from
Jan 9, 2024

Conversation

mightyiam
Copy link
Contributor

Co-authored-by: warren2k 846021+warren2k@users.noreply.github.com

@mightyiam
Copy link
Contributor Author

This is based on top of #720 . I suggest reviewing that one, first.

@mightyiam
Copy link
Contributor Author

Rebased. Please approve workflow and review. Reminder: this is based on top of #720.

@mightyiam
Copy link
Contributor Author

Our last workflow run failed. Force-pushed an attempt to resolve the issue. Please approve another workflow run.

@@ -35,7 +35,8 @@ jobs:
- uses: dtolnay/rust-toolchain@master
with:
toolchain: ${{ matrix.rust }}
- run: cargo check ${{ matrix.features }}
components: ${{ matrix.rust == 'stable' && 'clippy' || '' }}
Copy link
Member

Choose a reason for hiding this comment

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

Let's only run clippy on the msrv toolchain. Clippy recommendations that violate msrv are not actionable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Those could be allowed and reviewed on MSRV bumps? I'd imagine there's a lot of good lints between MSRV and stable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Your valid concern is that some clippy lints would suggest changes that include syntax or items that are not available in the minimum supported Rust version (MSRV).

Option A

In CI use MSRV clippy.

Those who have a more recent toolchain in their editor/IDE ("everyone") may be shown warnings from clippy lints that cannot be acted upon due to MSRV. Degraded developer experience.

Of course, those could be #[allow()]ed in order to improve the developer experience, but allowing those would not be enforced by CI.

And we'd have to invoke MSRV clippy in CI with --allow clippy::unknown_clippy_lints, allowing the unknown clippy lints inside of #[allow()].

Option B

In CI use stable clippy.

For the lints that would not be actionable in MSRV, #[allow()] them.
This would be enforced in CI. Better developer experience.

It seems that the lint unknown_lints does not apply to lints under the namespace clippy (clippy::*).

When bumping MSRV, go through all the allowed clippy lints in the codebase and examine which ones can now be acted upon.


It seems that option B would probably result in a better developer experience.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jswrenn again, we recommend option B. Call it and we'll do it.

wrappers.rs Outdated
Comment on lines 1 to 38
//! This module helps suppress two kinds of warnings: `deprecated` and `unstable_name_collisions`.
//! New items are created that are noop-wrappers of the original items.
//! The items' original paths are preserved.

use itertools::Itertools;

pub mod free {
// it seems the compiler is not able to discern that this is used
#[allow(dead_code)]
pub fn zip<I, J>(i: I, j: J) -> core::iter::Zip<I::IntoIter, J::IntoIter>
where I: IntoIterator,
J: IntoIterator
{
#[allow(deprecated)]
itertools::free::zip(i, j)
}
}

pub trait Ext: Itertools {
fn intersperse_wrap(self, element: Self::Item) -> itertools::Intersperse<Self>
where
Self: Sized,
Self::Item: Clone,
{
<Self as Itertools>::intersperse(self, element)
}

fn fold1_wrap<F>(self, f: F) -> Option<Self::Item>
where F: FnMut(Self::Item, Self::Item) -> Self::Item,
Self: Sized,
{
#[allow(deprecated)]
<Self as Itertools>::fold1(self, f)
}
}

impl<T: Itertools> Ext for T {}

Copy link
Member

Choose a reason for hiding this comment

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

As I wrote on #720, I'm not keen on the wrapper pattern to suppress warnings.

@mightyiam
Copy link
Contributor Author

Could you please approve workflow? This isn't ready, though.

@mightyiam mightyiam marked this pull request as draft September 17, 2023 15:01
Comment on lines 478 to 480

#[allow(clippy::explicit_counter_loop)]
for (_, elt) in data1.iter_mut().enumerate() {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

benches/bench1.rs Show resolved Hide resolved
benches/extra/zipslices.rs Show resolved Hide resolved
benches/fold_specialization.rs Show resolved Hide resolved
examples/iris.rs Show resolved Hide resolved
tests/quick.rs Show resolved Hide resolved
tests/test_std.rs Show resolved Hide resolved
src/lib.rs Show resolved Hide resolved
@@ -35,7 +35,8 @@ jobs:
- uses: dtolnay/rust-toolchain@master
with:
toolchain: ${{ matrix.rust }}
- run: cargo check ${{ matrix.features }}
components: ${{ matrix.rust == 'stable' && 'clippy' || '' }}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Those could be allowed and reviewed on MSRV bumps? I'd imagine there's a lot of good lints between MSRV and stable.

@@ -35,7 +35,8 @@ jobs:
- uses: dtolnay/rust-toolchain@master
with:
toolchain: ${{ matrix.rust }}
- run: cargo check ${{ matrix.features }}
components: ${{ matrix.rust == 'stable' && 'clippy' || '' }}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Your valid concern is that some clippy lints would suggest changes that include syntax or items that are not available in the minimum supported Rust version (MSRV).

Option A

In CI use MSRV clippy.

Those who have a more recent toolchain in their editor/IDE ("everyone") may be shown warnings from clippy lints that cannot be acted upon due to MSRV. Degraded developer experience.

Of course, those could be #[allow()]ed in order to improve the developer experience, but allowing those would not be enforced by CI.

And we'd have to invoke MSRV clippy in CI with --allow clippy::unknown_clippy_lints, allowing the unknown clippy lints inside of #[allow()].

Option B

In CI use stable clippy.

For the lints that would not be actionable in MSRV, #[allow()] them.
This would be enforced in CI. Better developer experience.

It seems that the lint unknown_lints does not apply to lints under the namespace clippy (clippy::*).

When bumping MSRV, go through all the allowed clippy lints in the codebase and examine which ones can now be acted upon.


It seems that option B would probably result in a better developer experience.

@jswrenn
Copy link
Member

jswrenn commented Oct 8, 2023

Alright, let's do clippy on stable. I don't like the idea that our CI might spontaneously break upon new Rust releases, but hopefully that's rare.

@mightyiam mightyiam marked this pull request as ready for review October 8, 2023 13:36
@mightyiam mightyiam requested a review from jswrenn October 8, 2023 13:37
@mightyiam
Copy link
Contributor Author

Looks like conflicts. I'll see what I can do.

@Philippe-Cholet
Copy link
Member

I don't know if we will apply CI changes, I leave that decision to jswrenn but I sure would like to fix lints.

@jswrenn
Copy link
Member

jswrenn commented Jan 7, 2024

Whoops, I must have missed when this PR was marked ready for review. I'm still fine running clippy with the stable toolchain.

Co-authored-by: warren2k <846021+warren2k@users.noreply.github.com>
Copy link
Contributor Author

@mightyiam mightyiam left a comment

Choose a reason for hiding this comment

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

Rebased and resolved 1.75.0 lints.

Comment on lines +478 to +479

#[allow(clippy::explicit_counter_loop, clippy::unused_enumerate_index)]
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'm not sure what this benchmark is about. I'm only guessing that calling enumerate and then ignoring the index is intentional. Same goes for the similar ones below.

Copy link
Member

Choose a reason for hiding this comment

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

@mightyiam After merging this PR, I search for PRs/issues about clippy (and closed some), saw #618 and eventually ran cargo clippy --all-targets and got clippy::unused_enumerate_index as "unknown lint" (yet I found it online). What am I missing here?
And second thing, we don't run clippy with --all-target and I'm wondering why, I don't see any discussion about it.

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 think we run clippy four times because of a matrix value features. One of the is --all-targets --all-features.

What version toolchain did you get an error with and what is the error exactly, please?

Copy link
Member

Choose a reason for hiding this comment

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

Ahh! unused_enumerate_index is added in 1.75 and I'm still on 1.74, my bad sorry! I'm so used on thinking I can't use recent features of Rust I did not thought it could be such a recent lint.
And another mistake of mine on matrix features. Ok, thanks!

@@ -500,6 +494,7 @@ impl<T> EitherOrBoth<T, T> {
}
}

#[allow(clippy::from_over_into)]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Does anyone know why we're implementing Into instead of From?

Copy link
Member

@Philippe-Cholet Philippe-Cholet Jan 8, 2024

Choose a reason for hiding this comment

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

I don't see a point of not doing it so I suggest you convert it to a From implementation in a separate commit.

EDIT: After searching, it originated in #327 and nobody said it should not be From instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here's an issue for that.

Now that shouldn't block this PR?

Copy link
Member

Choose a reason for hiding this comment

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

I sure want this PR to be merged as soon as possible as you made quite a work here!

src/multipeek_impl.rs Show resolved Hide resolved
src/tuple_impl.rs Show resolved Hide resolved
match *self {
Left(_) => true,
_ => false,
}
matches!(*self, Left(_))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

tests/quick.rs Show resolved Hide resolved
tests/quick.rs Show resolved Hide resolved
tests/test_std.rs Show resolved Hide resolved
tests/test_std.rs Show resolved Hide resolved
@mightyiam mightyiam marked this pull request as ready for review January 8, 2024 03:31
Copy link
Member

@Philippe-Cholet Philippe-Cholet left a comment

Choose a reason for hiding this comment

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

Thanks for updating your work.

@@ -500,6 +494,7 @@ impl<T> EitherOrBoth<T, T> {
}
}

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

@Philippe-Cholet Philippe-Cholet Jan 8, 2024

Choose a reason for hiding this comment

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

I don't see a point of not doing it so I suggest you convert it to a From implementation in a separate commit.

EDIT: After searching, it originated in #327 and nobody said it should not be From instead.

@Philippe-Cholet
Copy link
Member

So we chose "Option B" from your #740 (comment) in which you mention something interesting.

When bumping MSRV, go through all the allowed clippy lints in the codebase and examine which ones can now be acted upon.

I think we might easily forgot that so I think that we should have a comment on the "rust-version" line in "Cargo.toml".
Once done, I'll merge this PR as jswrenn's last comment is enough confirmation to me.

Copy link

@bishopcheckmate bishopcheckmate left a comment

Choose a reason for hiding this comment

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

nit, actually dereferencing is not needed

Left(_) => true,
_ => false,
}
matches!(*self, Left(_))

Choose a reason for hiding this comment

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

Suggested change
matches!(*self, Left(_))
matches!(self, Left(_))

Copy link
Member

Choose a reason for hiding this comment

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

Indeed, it compiles to the exact same thing (I just checked a simple example on godbolt).
I'm not sure we should care when I did not find any clippy lint for it.
I'll let the author decide here.

Choose a reason for hiding this comment

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

yeah, that's definitely a nitpick. on the other hand in a pr which satisfies clippy, it might be kind of future proofing 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry thank you done.

Right(_) => true,
_ => false,
}
matches!(*self, Right(_))

Choose a reason for hiding this comment

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

Suggested change
matches!(*self, Right(_))
matches!(self, Right(_))

Co-authored-by: warren2k <846021+warren2k@users.noreply.github.com>
Comment on lines +18 to 19
# When bumping, please resolve all `#[allow(clippy::*)]` that are newly resolvable.
rust-version = "1.43.1"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added this here. Good enough?

Copy link
Member

@Philippe-Cholet Philippe-Cholet left a comment

Choose a reason for hiding this comment

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

This is it, thanks for your dedicated work. 🎉

@Philippe-Cholet Philippe-Cholet added this pull request to the merge queue Jan 9, 2024
Merged via the queue into rust-itertools:master with commit c5a1b16 Jan 9, 2024
8 checks passed
@mightyiam mightyiam deleted the clippy branch January 9, 2024 08:25
@Philippe-Cholet Philippe-Cholet added this to the next milestone Jan 10, 2024
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.

4 participants