[Merged by Bors] - Clippy improvements

[ManevilleF]

Objective

Follow up to my previous MR #3718 to add new clippy warnings to bevy:

• option_if_let_else (reverted)
• redundant_else
• match_same_arms
• semicolon_if_nothing_returned
• explicit_iter_loop
• 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

[alice-i-cecile]

Can we use some string parsing to list out these lints in a cleaner fashion?

[ManevilleF]

I tried many different ways but xshell (even updated to 0.2) keeps printing the flags between double quotes, so I gave up

[infmagic2047]

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...}")

[ManevilleF]

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

[ManevilleF]

@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"

[infmagic2047]

-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.

[ManevilleF]

Thanks that seems to work, committing now

[alice-i-cecile]

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 @cart's attention (view) to try to avoid bitrot.

[alice-i-cecile]

Note: this gets the Controversial tag because it's a project-wide change to style.

[james7132]

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.

[mockersf]

map_or and map_or_else are bad for readability as they have the map closure as second parameter

[ManevilleF]

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

[ManevilleF]

I reverted the changes from the first commit (clippy::option_if_let_else) and removed the clippy warning in the CI.

Every added map_or and map_or_else was reverted, I just left a few instances of map where I thought it was better. I can revert those changes if necessary.

@mockersf @alice-i-cecile

[ManevilleF]

Rebased on staging, fixed additional warnings

[IceSentry]

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.

[james7132]

Less code is better code. This doubles as a great cleanup as well.

[james7132]

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.

I personally like it because it just avoids the pressure to push code to the right, particularly if the code block is large.

[ManevilleF]

Rebased on staging and fixed additional warnings. Maybe I should change the MR target to staging instead of main ? I'm not sure what the role of staging is

@IceSentry I don't think having a redundant else (meaning you return in the if) adds clarity, but maybe enforcing that rule is a bit much.

@james7132 Thanks for the review

[IceSentry]

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 return.

I still think it shouldn't be forced through a lint, but I'm not as opposed to it as I originally was.

[cart]

Just resolved conflicts, rebased, and removed our manual allow(type_complexity) cases, now that they are allowed by default.

[cart]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• check-unused-dependencies
• ci
• markdownlint
• miri
• run-examples