Skip to content

Make Clippy stricter #239

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

Merged
merged 2 commits into from
Jan 6, 2022
Merged

Make Clippy stricter #239

merged 2 commits into from
Jan 6, 2022

Conversation

adamreichold
Copy link
Member

But disable needless-lifetimes lint as we often want to make the GIL lifetime explicit.

It seems preferable to have a clean CI based on stable Clippy,
than to accomodate a not-yet-released version.
@adamreichold
Copy link
Member Author

Sorry for the back and forth w.r.t. Clippy lints, I am running nightly locally but I do not think this is something that should be encouraged by the CI as the Clippy lints change quite often.

Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

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

Thanks, LGTM 👍

Allowing needless-lifetimes is an interesting idea - I can see being explicit about the GIL is a good thing (although seeing lifetimes does scare new users sometimes). I might consider doing similar in PyO3...

Copy link
Member

@kngwyu kngwyu left a comment

Choose a reason for hiding this comment

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

👍🏼

@@ -448,7 +448,7 @@ impl<T: Element, D: Dimension> PyArray<T, D> {
ID: IntoDimension<Dim = D>,
{
let dims = dims.into_dimension();
let data_ptr = data_ptr.unwrap_or(boxed_slice.as_ptr());
let data_ptr = data_ptr.unwrap_or_else(|| boxed_slice.as_ptr());
Copy link
Member

Choose a reason for hiding this comment

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

I should have pointed out when reviewing (I thought recent clippy is OK with this...)

Copy link
Member Author

Choose a reason for hiding this comment

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

Exactly, current nightly Clippy actually wants the version without the closure whereas current stable Clippy complains about it. I think nightly Clippy is right, as boxed_slice.as_ptr() does not cost anything that should be delayed by wrapping it in a closure. So I expect to change this again with the next stable Clippy release. But as written above, the most important thing is to have a systematic check of this stuff via the CI.

@kngwyu kngwyu merged commit 4cb5a44 into PyO3:main Jan 6, 2022
@adamreichold adamreichold deleted the stricter-clippy branch January 6, 2022 09:00
@aldanor
Copy link
Contributor

aldanor commented Jan 10, 2022

Can the clippy config be added to lib.rs?

Might not be the nicest way to handle it, but it's quite common. This way any contributor can just run cargo clippy at any point of time without having to copy/paste the current flags from the CI config (or having to update them if they changed). Similarly, on CI you just run cargo clippy without any further tweaks.

@adamreichold
Copy link
Member Author

Can the clippy config be added to lib.rs?

The allow lifetimes part, yes. The deny warnings part not as this might break builds. Will add this to #251 as I touch the Clippy flags there anyway.

@aldanor
Copy link
Contributor

aldanor commented Jan 10, 2022

What I found useful in the crates that I maintain is doing something like this at crate root:

#![warn(clippy::pedantic, clippy::nursery, clippy::all)]
#![allow(clippy:this, clippy:that, clippy:whatever)]

There's tons of useful lints out there that are not enabled by default (but there's also some e.g. related to crate metadata that can be disabled).

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