-
Notifications
You must be signed in to change notification settings - Fork 7
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
Custom clippy configuration #478
Conversation
Codecov Report
@@ Coverage Diff @@
## master #478 +/- ##
=======================================
Coverage 58.02% 58.02%
=======================================
Files 216 216
Lines 15942 15942
=======================================
Hits 9250 9250
Misses 6692 6692
📣 We’re building smart automated test selection to slash your CI/CD build times. 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.
Nice, ya I think that this is a great idea - thanks! I'm also in favour of the rules that you laid out initially. Obviously, I would try to go lower than 5 if I could, but I can agree that it's probably a more reasonable hard rule, as you say
@@ -34,6 +37,7 @@ fn make_tag_part(pieces: Vec<&str>) -> Option<Vec<BuildKeyVersionNumberPiece>> { | |||
|
|||
// For making test case results | |||
#[allow(clippy::too_many_arguments)] | |||
#[allow(clippy::fn_params_excessive_bools)] |
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.
Allowing this here as the one special case in the code base.
#![deny(unsafe_op_in_unsafe_fn)] | ||
#![warn(clippy::fn_params_excessive_bools)] | ||
|
||
use std::sync::Arc; |
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.
Fixed a misplaced import here.
@rydrman please do another look before I merge this. I added comments to the changes that aren't just adding deny/warn to all the files. |
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 thought that we could put the lint attributes at the crate level and not need to apply them to every module, or am I misreading these diffs?
I'm not sure, I put it everywhere.
…On Fri, Feb 24, 2023, 10:16 PM Ryan Bottriell ***@***.***> wrote:
***@***.**** commented on this pull request.
I thought that we could put the lint attributes at the crate level and not
need to apply them to every module, or am I misreading these diffs?
—
Reply to this email directly, view it on GitHub
<#478 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAA3LMBSM5LTTCK32THWR3WZGPSLANCNFSM57VCAVMA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Do you know of a way to return a list of files in the project that are "at
crate level"?
…On Fri, Feb 24, 2023, 10:22 PM J Robert Ray ***@***.***> wrote:
I'm not sure, I put it everywhere.
On Fri, Feb 24, 2023, 10:16 PM Ryan Bottriell ***@***.***>
wrote:
> ***@***.**** commented on this pull request.
>
> I thought that we could put the lint attributes at the crate level and
> not need to apply them to every module, or am I misreading these diffs?
>
> —
> Reply to this email directly, view it on GitHub
> <#478 (review)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAA3LMBSM5LTTCK32THWR3WZGPSLANCNFSM57VCAVMA>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
I think it would just be every |
Anything listed as a target in any Cargo.toml, build scripts, etc.
…On Sat, Feb 25, 2023, 1:23 PM Ryan Bottriell ***@***.***> wrote:
I think it would just be every lib.rs file
—
Reply to this email directly, view it on GitHub
<#478 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAA3LKULZI7O2XNG4KTC3LWZJZ4LANCNFSM57VCAVMA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Enable checking of excessive bool parameters in all crates, and limit to 1. Limit the number of arguments to 5. Signed-off-by: J Robert Ray <jrray@jrray.org>
I've taken the directives out of most files. The nice thing about having it in every file is that it is straightforward to verify that the directives are present and active in every file. |
This is a step towards having some coding and style conventions for this project "in writing" that we can all discuss and agree on, focusing on two things have been a frequent point of contention in code reviews.
The use of bools in function parameters can be monitored by clippy. This is a "pedantic" check so it is not enabled by default. I put the attr in every lib.rs to enable it. Our codebase passes with this set to 1, with one exception, where the warning has been supressed. I agree with the sentiment of the clippy lint text, "calls to such functions [with excessive use of bools] are confusing and error prone," particularly if there are multiple consecutive bool arguments. But rather than banning bool arguments entirely, allowing a single bool argument avoids the confusing argument order problem.
The threshold for too many arguments is enabled by default, but has a default limit of 7. For our codebase, 5 is the lowest it can go without triggering any warnings. My personal preference is to not try to go lower than 5.
Interestingly, this was the #2 most ignored lint: rust-lang/rust-clippy#7666 As noted in the comments, this is most likely due to
new
constructors for complex structs requiring many arguments.