-
Notifications
You must be signed in to change notification settings - Fork 308
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
clippy #740
Conversation
This is based on top of #720 . I suggest reviewing that one, first. |
f88da92
to
8769af0
Compare
Rebased. Please approve workflow and review. Reminder: this is based on top of #720. |
Our last workflow run failed. Force-pushed an attempt to resolve the issue. Please approve another workflow run. |
.github/workflows/ci.yml
Outdated
@@ -35,7 +35,8 @@ jobs: | |||
- uses: dtolnay/rust-toolchain@master | |||
with: | |||
toolchain: ${{ matrix.rust }} | |||
- run: cargo check ${{ matrix.features }} | |||
components: ${{ matrix.rust == 'stable' && 'clippy' || '' }} |
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 only run clippy on the msrv toolchain. Clippy recommendations that violate msrv are not actionable.
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 could be allowed and reviewed on MSRV bumps? I'd imagine there's a lot of good lints between MSRV and stable.
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.
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.
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.
@jswrenn again, we recommend option B. Call it and we'll do it.
wrappers.rs
Outdated
//! 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 {} | ||
|
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.
As I wrote on #720, I'm not keen on the wrapper pattern to suppress warnings.
Could you please approve workflow? This isn't ready, though. |
df848e0
to
5b0235a
Compare
benches/bench1.rs
Outdated
|
||
#[allow(clippy::explicit_counter_loop)] | ||
for (_, elt) in data1.iter_mut().enumerate() { |
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.
Benchmarks are kind of weird code, anyway.
https://rust-lang.github.io/rust-clippy/master/index.html#/explicit_counter_loop
.github/workflows/ci.yml
Outdated
@@ -35,7 +35,8 @@ jobs: | |||
- uses: dtolnay/rust-toolchain@master | |||
with: | |||
toolchain: ${{ matrix.rust }} | |||
- run: cargo check ${{ matrix.features }} | |||
components: ${{ matrix.rust == 'stable' && 'clippy' || '' }} |
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 could be allowed and reviewed on MSRV bumps? I'd imagine there's a lot of good lints between MSRV and stable.
.github/workflows/ci.yml
Outdated
@@ -35,7 +35,8 @@ jobs: | |||
- uses: dtolnay/rust-toolchain@master | |||
with: | |||
toolchain: ${{ matrix.rust }} | |||
- run: cargo check ${{ matrix.features }} | |||
components: ${{ matrix.rust == 'stable' && 'clippy' || '' }} |
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.
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.
c9f2887
to
1211903
Compare
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. |
Looks like conflicts. I'll see what I can do. |
I don't know if we will apply CI changes, I leave that decision to jswrenn but I sure would like to fix lints. |
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>
f93e8f4
to
abb3f50
Compare
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.
Rebased and resolved 1.75.0 lints.
|
||
#[allow(clippy::explicit_counter_loop, clippy::unused_enumerate_index)] |
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 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.
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.
@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.
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 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?
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.
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)] |
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.
Does anyone know why we're implementing Into instead of From?
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 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.
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.
Here's an issue for that.
Now that shouldn't block this PR?
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 sure want this PR to be merged as soon as possible as you made quite a work here!
src/either_or_both.rs
Outdated
match *self { | ||
Left(_) => true, | ||
_ => false, | ||
} | ||
matches!(*self, Left(_)) |
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.
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.
Thanks for updating your work.
@@ -500,6 +494,7 @@ impl<T> EitherOrBoth<T, T> { | |||
} | |||
} | |||
|
|||
#[allow(clippy::from_over_into)] |
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 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.
So we chose "Option B" from your #740 (comment) in which you mention something interesting.
I think we might easily forgot that so I think that we should have a comment on the "rust-version" line in "Cargo.toml". |
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.
nit, actually dereferencing is not needed
src/either_or_both.rs
Outdated
Left(_) => true, | ||
_ => false, | ||
} | ||
matches!(*self, Left(_)) |
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.
matches!(*self, Left(_)) | |
matches!(self, Left(_)) |
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.
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.
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, that's definitely a nitpick. on the other hand in a pr which satisfies clippy, it might be kind of future proofing 😄
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.
Sorry thank you done.
src/either_or_both.rs
Outdated
Right(_) => true, | ||
_ => false, | ||
} | ||
matches!(*self, Right(_)) |
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.
matches!(*self, Right(_)) | |
matches!(self, Right(_)) |
Co-authored-by: warren2k <846021+warren2k@users.noreply.github.com>
# When bumping, please resolve all `#[allow(clippy::*)]` that are newly resolvable. | ||
rust-version = "1.43.1" |
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.
Added this here. Good enough?
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 it, thanks for your dedicated work. 🎉
Co-authored-by: warren2k 846021+warren2k@users.noreply.github.com