-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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 by Bors] - Clippy improvements #4665
Conversation
tools/ci/src/main.rs
Outdated
@@ -46,7 +46,7 @@ fn main() { | |||
if what_to_run.contains(Check::CLIPPY) { | |||
// See if clippy has any complaints. | |||
// - Type complexity must be ignored because we use huge templates for queries | |||
cmd!("cargo clippy --workspace --all-targets --all-features -- -A clippy::type_complexity -W clippy::doc_markdown -D warnings") | |||
cmd!("cargo clippy --workspace --all-targets --all-features -- -A clippy::type_complexity -W clippy::doc_markdown -W clippy::option_if_let_else -W clippy::redundant_else -W clippy::match_same_arms -W clippy::semicolon_if_nothing_returned -W clippy::explicit_iter_loop -W clippy::map_flatten -D warnings") |
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.
Can we use some string parsing to list out these lints in a cleaner fashion?
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 tried many different ways but xshell
(even updated to 0.2) keeps printing the flags between double quotes, so I gave up
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 pretty sure that xshell
doesn't do argument splitting outside cmd!
macro, so we need to keep the flags in a vec and expand like cmd!("cargo clippy {args...}")
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 tried that, and it still printed every flag between double quotes even though I'm sure I did exactly as the xshell
doc does 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.
@infmagic2047 wether flags
are stored in a Vec<&str>
, a Vec<String>
, or a [&str]
, const
or in a let
:
let flags = vec![
"-A clippy::type_complexity",
"-W clippy::doc_markdown",
"-W clippy::option_if_let_else",
"-W clippy::redundant_else",
"-W clippy::match_same_arms",
"-W clippy::semicolon_if_nothing_returned",
"-W clippy::explicit_iter_loop",
"-W clippy::map_flatten",
"-D warnings",
];
cmd!("cargo clippy --workspace --all-targets --all-features -- {flags...}")
This is the output:
cargo clippy --workspace --all-targets --all-features -- "-A clippy::type_complexity" "-W clippy::doc_markdown" "-W clippy::option_if_let_else" "-W clippy::redundant_else" "-W clippy::match_same_arms" "-W clippy::semicolon_if_nothing_returned" "-W clippy::explicit_iter_loop" "-W clippy::map_flatten" "-D warnings"
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.
-A clippy::type_complexity
is actually two arguments -A
and clippy::type_complexity
, so writing them as one won't work. You can either write them as two elements, or use the concatenated form -Aclippy::type_complexity
.
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 that seems to work, committing now
I like these lints; I think they add clarity and consistency without being tedious or frustrating. The corresponding code changes are good: I think these are clear improvements in every case. Added as a candidate to https://github.com/orgs/bevyengine/projects/4/views/1 to try to avoid bitrot. |
Note: this gets the Controversial tag because it's a project-wide change to style. |
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.
While I can agree with most of these changes, the use of map_or_else
is a regression in terms of readability IMO. The use of two closures makes it visually hard to tell which branch is which.
|
I agree that in the case of large closures it's not great, I rwill ollback the changes and the restriction but should every change be rollbacked? For example the changes in crates/bevy_ecs/src/schedule/run_criteria.rs we go from: if let Some(ref label) = self.label {
std::slice::from_ref(label)
} else {
&[]
} to self.label.as_ref().map_or(&[], std::slice::from_ref) which to me is a clear improvement |
I reverted the changes from the first commit (clippy::option_if_let_else) and removed the clippy warning in the CI. Every added |
bc9bce2
to
1ad1b3d
Compare
Rebased on staging, fixed additional warnings |
I'm not a huge fan of having redundant_else as a rule. I agree that it can sometimes be redundant, but in some situations I think it's clearer to show that each block are separate branches. I don't like that it's enforced in all situations. I haven't seen that many situations in this PR where the end result was necessarily worse, but I don't like enforcing that rule. |
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.
Less code is better code. This doubles as a great cleanup as well.
I personally like it because it just avoids the pressure to push code to the right, particularly if the code block is large. |
1ad1b3d
to
7ab1bb2
Compare
Rebased on staging and fixed additional warnings. Maybe I should change the MR target to @IceSentry I don't think having a redundant else (meaning you @james7132 Thanks for the review |
So apparently I was misunderstanding the redundant_else lint. I thought it would complain about code like this fn foo(input: i32) -> String {
if input == 42 {
String::from("The answer!")
} else {
String::from("Wrong answerr")
}
} to turn it into this fn foo(input: i32) -> String {
if input == 42 {
return String::from("The answer!");
}
String::from("Wrong")
} just to avoid the last else, but that's not actually what it warns about. It will only warn if the else can be removed without adding or removing a I still think it shouldn't be forced through a lint, but I'm not as opposed to it as I originally was. |
bae6e2c
to
9cea556
Compare
9cea556
to
4227dbf
Compare
Just resolved conflicts, rebased, and removed our manual |
bors r+ |
# Objective Follow up to my previous MR #3718 to add new clippy warnings to bevy: - [x] [~~option_if_let_else~~](https://rust-lang.github.io/rust-clippy/master/#option_if_let_else) (reverted) - [x] [redundant_else](https://rust-lang.github.io/rust-clippy/master/#redundant_else) - [x] [match_same_arms](https://rust-lang.github.io/rust-clippy/master/#match_same_arms) - [x] [semicolon_if_nothing_returned](https://rust-lang.github.io/rust-clippy/master/#semicolon_if_nothing_returned) - [x] [explicit_iter_loop](https://rust-lang.github.io/rust-clippy/master/#explicit_iter_loop) - [x] [map_flatten](https://rust-lang.github.io/rust-clippy/master/#map_flatten) There is one commit per clippy warning, and the matching flags are added to the CI execution. To test the CI execution you may run `cargo run -p ci -- clippy` at the root. I choose the add the flags in the `ci` tool crate to avoid having them in every `lib.rs` but I guess it could become an issue with suprise warnings coming up after a commit/push Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective Follow up to my previous MR bevyengine#3718 to add new clippy warnings to bevy: - [x] [~~option_if_let_else~~](https://rust-lang.github.io/rust-clippy/master/#option_if_let_else) (reverted) - [x] [redundant_else](https://rust-lang.github.io/rust-clippy/master/#redundant_else) - [x] [match_same_arms](https://rust-lang.github.io/rust-clippy/master/#match_same_arms) - [x] [semicolon_if_nothing_returned](https://rust-lang.github.io/rust-clippy/master/#semicolon_if_nothing_returned) - [x] [explicit_iter_loop](https://rust-lang.github.io/rust-clippy/master/#explicit_iter_loop) - [x] [map_flatten](https://rust-lang.github.io/rust-clippy/master/#map_flatten) There is one commit per clippy warning, and the matching flags are added to the CI execution. To test the CI execution you may run `cargo run -p ci -- clippy` at the root. I choose the add the flags in the `ci` tool crate to avoid having them in every `lib.rs` but I guess it could become an issue with suprise warnings coming up after a commit/push Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective Follow up to my previous MR bevyengine#3718 to add new clippy warnings to bevy: - [x] [~~option_if_let_else~~](https://rust-lang.github.io/rust-clippy/master/#option_if_let_else) (reverted) - [x] [redundant_else](https://rust-lang.github.io/rust-clippy/master/#redundant_else) - [x] [match_same_arms](https://rust-lang.github.io/rust-clippy/master/#match_same_arms) - [x] [semicolon_if_nothing_returned](https://rust-lang.github.io/rust-clippy/master/#semicolon_if_nothing_returned) - [x] [explicit_iter_loop](https://rust-lang.github.io/rust-clippy/master/#explicit_iter_loop) - [x] [map_flatten](https://rust-lang.github.io/rust-clippy/master/#map_flatten) There is one commit per clippy warning, and the matching flags are added to the CI execution. To test the CI execution you may run `cargo run -p ci -- clippy` at the root. I choose the add the flags in the `ci` tool crate to avoid having them in every `lib.rs` but I guess it could become an issue with suprise warnings coming up after a commit/push Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Objective
Follow up to my previous MR #3718 to add new clippy warnings to bevy:
option_if_let_else(reverted)There is one commit per clippy warning, and the matching flags are added to the CI execution.
To test the CI execution you may run
cargo run -p ci -- clippy
at the root.I choose the add the flags in the
ci
tool crate to avoid having them in everylib.rs
but I guess it could become an issue with suprise warnings coming up after a commit/push