-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
CI doesn't know about it yet.
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.
CI now should have clippy thanks to cumulus: paritytech/scripts#342 |
I'm personally not convinced about clippy and its value. People can use clippy locally as part of their IDE and fix what it complains about in their code, but in overall I don't see any need to force everyone to use this. |
It's clear that we adhere to subsets of clippy's rules.
For example if we run
```
cargo clippy -- -A clippy::all -D clippy::correctness
```
on substrate then there's only one violation from that set of rules in the
codebase - `unsafe fn memory_as_slice_mut(&self) -> &mut[u8]`.
That's a pretty good sign that our values and clippys values align for
certain categories of lints. I'm not suggesting we turn clippy up to 11,
but I do think there's value turning it up from 0 currently to 3 or 4. At
some point it's going to catch a prod issue before it escapes into the wild.
…On Sun, 19 Sept 2021 at 13:23, Bastian Köcher ***@***.***> wrote:
I'm personally not convinced about clippy and its value.
People can use clippy locally as part of their IDE and fix what it
complains about in their code, but in overall I don't see any need to force
everyone to use this.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#9694 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGEJCCA7IRJPVPZDHCO6B3UCXI3LANCNFSM5DNPFPOQ>
.
|
I'm personally not a fan of Clippy, nor have I ever found a good spot for it in my workflow locally. But I am open to allowing some lints that don't have a huge initial impact and gradually find a balance. |
I like clippy and its community; more than once I've learned about some new Rust feature through its warnings. If we do this sensibly (read: avoiding pedantry) and gradually I have no objections. |
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.
Btw why not a toml config?
Just focusing on the correctness lints. There's a couple of places where we
Hmm, I think this way round is not so much of a problem - if we were just deriving Hash we could introduce a bug here, but these definitions look ok to me. |
To be merged after #9637 |
Someone somewhere asked about how rust analyser would stay in sync with the clippy lints defined in the .sh file. |
This relies on a compiler patch that landed 8th July 2021. If people are using an earlier version of the compiler everything will still work unless they try and run clippy.
Co-authored-by: Bastian Köcher <[email protected]>
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.
People can use clippy locally as part of their IDE and fix what it complains about in their code, but in overall I don't see any need to force everyone to use this.
I am in favor on enforcing clippy globally because I never found a way to do exactly this. rust-analyzer annoys me with warnings from the whole workspace no matter in which sub directory I open my IDE in.
Even clippy critics seem to care about the issues that clippy has raised here, so clippy as currently configured seems to be focusing on the right things and is providing us with additional assurances (while not being too noisy). I'm going to merge this as there's sufficient thumbs-up thought I do note that people are in two minds about this. Let's try it for a few weeks and see if it causes any disruption. We can rollback easily or mute certain lints if they're not paying their way. |
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.
Aight to merge after these nits. Those who will have to rebase on this should not face much trouble.
It appears that there is support for a Why aren't we using this? |
Clippy.toml only allows you to specify how much cyclometric complexity you're willing to tolerate etc. It does not allow you to specify whether to allow or deny any of the lints. There's a very long thread on this: TL/DR looks like there's a PR to allow common metadata in workspaces; after that they might make it specifiable in Cargo.toml. The reason for Clippy.toml not being in the running is that these clippy allow / deny should be specified in the same way as tuning on/off rustc lints are. (They have been debating this point for 5 years now, meanwhile as of July this year, the |
I see thanks. |
Co-authored-by: Denis Pisarev <[email protected]>
* master: (125 commits) Update multiple dependencies (#9936) Speed up timestamp generation when logging (#9933) First word should be Substrate not Polkadot (#9935) Improved file not found error message (#9931) don't read events in elections anymore. (#9898) Remove incorrect sanity check (#9924) Require crypto scheme for `insert-key` (#9909) chore: refresh of the substrate_builder image (#9808) Introduce block authorship soft deadline (#9663) Rework Transaction Priority calculation (#9834) Do not propagate host RUSTFLAGS when checking for WASM toolchain (#9926) Small quoting comment fix (#9927) add clippy to CI (#9694) Ensure BeforeBestBlockBy voting rule accounts for base (#9920) rm `.maintain` lock (#9919) Downstream `node-template` pull (#9915) Implement core::fmt::Debug for BoundedVec (#9914) Quickly skip invalid transactions during block authorship. (#9789) Add SS58 prefix for Automata (#9805) Clean up sc-peerset (#9806) ...
This PR enforces the majority of the lints from clippy's correctness category.
Future PRs can gradually turn additional lints on where we all agree there's value in the lint.