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

chore: Implement latest clippy warnings #3220

Merged

Conversation

umgefahren
Copy link
Contributor

@umgefahren umgefahren commented Dec 9, 2022

Description

As I do frequently, I corrected for the latest clippy warnings. This will make sure the CI won't complain in the future. We could automate this btw and maybe run the nightly version of clippy.

Change checklist

  • I have performed a self-review of my own code

(No changes to pubic APIs)

@umgefahren
Copy link
Contributor Author

I discovered a really mysterious function. Could someone explain the async block in this swarm test. This async block doesn't make any sense. Since it's not executed we could avoid the async block. But I don't know what we want to test here.

Copy link
Member

@jxs jxs left a comment

Choose a reason for hiding this comment

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

Looks good to me overall!

@@ -1425,7 +1425,8 @@ where
// check the flood cutoff
let flood_cutoff = (backoff_time
+ self.config.graft_flood_threshold())
- self.config.prune_backoff();
.checked_sub(self.config.prune_backoff())
.unwrap();
Copy link
Member

Choose a reason for hiding this comment

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

this seems to be unchecked_duration_subtraction right?
If so, we are switching a possible unintentional panic for an unwrap. I'd give it more context with expect.
(the same applies for the other .checked_sub().unwrap() substitutions)

Copy link
Contributor Author

@umgefahren umgefahren Dec 9, 2022

Choose a reason for hiding this comment

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

Yes I think you are correct. I must have overlooked it (I tried to vet the automatic fixes but you know...)

This could be a bug. I'll look into filing an issue. Simply because the panic from the arithmetic error is probably more descriptive then calling unwrap on an empty option.

Copy link
Member

Choose a reason for hiding this comment

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

yeah, makes sense. Thanks Hannes.

@umgefahren
Copy link
Contributor Author

Let's wait until I get feedback on rust-lang/rust-clippy#10061.

@thomaseizinger
Copy link
Contributor

We could automate this btw

Are you suggesting a workflow that automatically opens a PR with cargo clippy --fix changes? I think that could be a cool GitHub action in general. Knock yourself out 😁

maybe run the nightly version of clippy.

We run beta. I think that makes more sense because those are likely to be more stable so less false positives and less churn :)

@rkuhn
Copy link
Contributor

rkuhn commented Dec 10, 2022

Just my 2c: clippy has crossed from useful into useless land long ago … it is mostly churn with each new release now. Implementing suggestions would have made my code worse on several occasions and introduced subtle bugs. Automating that is not a good idea. (yes, I tried raising issues, but the clippy crew is somewhat religious about their kraken)

@thomaseizinger
Copy link
Contributor

I discovered a really mysterious function. Could someone explain the async block in this swarm test. This async block doesn't make any sense. Since it's not executed we could avoid the async block. But I don't know what we want to test here.

The async block allows us to .await which means we can match on the event which asserts which type is returned in SwarmEvent::Behaviour.

Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

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

@umgefahren
Copy link
Contributor Author

umgefahren commented Dec 12, 2022

Looks good to me minus the discussion https://github.com/libp2p/rust-libp2p/pull/3220/files#r1044889735.

Thanks @umgefahren!

I suggest just waiting until they figured out what to do over there. If they will stick with their plans I understand #3220 (comment). Although, personally, I never experienced any issues with clippy and always considered it a good tool for encouraging idiomatic Rust. It's just, as every linter, heavily opinionated. I really like your last sentence though, should remember that... 😄

They will decide tomorrow 16:00 UTC. I'll decide what to do then.

@umgefahren
Copy link
Contributor Author

I discovered a really mysterious function. Could someone explain the async block in this swarm test. This async block doesn't make any sense. Since it's not executed we could avoid the async block. But I don't know what we want to test here.

The async block allows us to .await which means we can match on the event which asserts which type is returned in SwarmEvent::Behaviour.

But why not just make the entire function async? It's just a compilation test anyway and it has no influence on that. I might be mistaken here.

@rkuhn
Copy link
Contributor

rkuhn commented Dec 12, 2022

It's just, as every linter, heavily opinionated.

For the record: that’s a very good thing as far as I’m concerned! The issue is when opinion clashes with correctness, i.e. when the linter regulates aspects that are not subject to stylistic choices. I’d be very careful around lints that change

  • borrowing, especially in async blocks (“needless_collect” is a frequent offender — this issue stems from a language bug that requires values borrowed across .await implement Sync even though access will be via an exclusive reference only (cf. signature of poll))
  • locking (which is just borrowing of a guard): correctness may place non-local constraints on how long a lock can at most be held, i.e. which actions are not permitted to be performed while holding the lock; clippy cannot know the rules, yet it feels entitled to make suggestions

As an example of useless churn consider explicit_auto_deref, which hides essential detail from people who read code without an IDE.

@mergify
Copy link
Contributor

mergify bot commented Dec 12, 2022

This pull request has merge conflicts. Could you please resolve them @umgefahren? 🙏

@thomaseizinger
Copy link
Contributor

thomaseizinger commented Dec 12, 2022

I discovered a really mysterious function. Could someone explain the async block in this swarm test. This async block doesn't make any sense. Since it's not executed we could avoid the async block. But I don't know what we want to test here.

The async block allows us to .await which means we can match on the event which asserts which type is returned in SwarmEvent::Behaviour.

But why not just make the entire function async?

I think that is a possibility yes.

@mxinden
Copy link
Member

mxinden commented Dec 14, 2022

Our CI currently fails on our clippy check. See e.g. https://github.com/libp2p/rust-libp2p/actions/runs/3694864006/jobs/6256559595. That would be fixed with this pull request.

Contrary to what I suggested before, with the above in mind I suggest we move forward and delay #3220 (comment) to another pull request.

@mxinden
Copy link
Member

mxinden commented Dec 14, 2022

Preparing a merge commit right now.

@umgefahren
Copy link
Contributor Author

They decided to move it to the restriction group (https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Meeting.202022-12-13/near/315627353). It might take some time to implement the change though. I don't have any information here. I will revert the changes in that file for now.

@mergify mergify bot merged commit d79c93a into libp2p:master Dec 14, 2022
@mxinden
Copy link
Member

mxinden commented Dec 14, 2022

Thanks @umgefahren!

@thomaseizinger
Copy link
Contributor

Our CI currently fails on our clippy check. See e.g. https://github.com/libp2p/rust-libp2p/actions/runs/3694864006/jobs/6256559595. That would be fixed with this pull request.

Contrary to what I suggested before, with the above in mind I suggest we move forward and delay #3220 (comment) to another pull request.

Only the clippy (beta) though which is not required for merging! :)

@thomaseizinger
Copy link
Contributor

@Mergifyio backport rust-v050-testplan

mergify bot pushed a commit that referenced this pull request Feb 15, 2023
As I do frequently, I corrected for the latest clippy warnings. This will make sure the CI won't complain in the future. We could automate this btw and maybe run the nightly version of clippy.

(cherry picked from commit d79c93a)

# Conflicts:
#	protocols/request-response/tests/ping.rs
#	transports/webrtc/tests/smoke.rs
@mergify
Copy link
Contributor

mergify bot commented Feb 15, 2023

backport rust-v050-testplan

✅ Backports have been created

umgefahren added a commit to umgefahren/rust-libp2p that referenced this pull request Mar 8, 2024
As I do frequently, I corrected for the latest clippy warnings. This will make sure the CI won't complain in the future. We could automate this btw and maybe run the nightly version of clippy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants