auto-fix for redundant_else lint

[lapla-cogito]

changelog: [redundant_else]: auto-fix when appropriate

redundant_else can be fixed automatically.

[rustbot]

r? @Jarcho

rustbot has assigned @Jarcho.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[samueltardieu]

What if the else block declares variables? Not only will they be dragged into the outer scope, but also their dropping will be deferred until the end of the outer scope, which may be problematic in case of a guard.

For example, the PR fails with this code:

fn with_drop(t: bool) -> u32 {
    let a = 42;
    if t {
        return 0;
    } else {
        let a = "foobar";
        println!("this a = {a}");
    }
    a + 1
}

because let a = "foobar"; has been dragged into the outer scope and hides the outer a. Here the example is constructed specially to exhibit the failure, but with a mutex guard we might have real issues.

Maybe the suggestion should apply only when no bindings are introduced inside the else block, even though the lint could warn about the redundant else.

[samueltardieu]

Another (very minor) issue is that if the fix belongs to a macro, the indentation shown will be the one of the macro call, not the proper one, e.g.,

macro_rules! mac {
    ($t:expr) => {{
        if $t {
            return 0;
        } else {
            return 42;
        }
    }}
}

fn call_macro() -> u32 {
                       mac!(true)
}

will suggest using

macro_rules! mac {
    ($t:expr) => {{
        if $t {
            return 0;
        }
                       return 42;
    }}
}

[lapla-cogito]

r? clippy

[lapla-cogito]

Commits are now squashed.

[lapla-cogito]

note: I'd like to hear what the reviewers think about this issue, i.e., since I think this is usually a (very) minor issue, I'd like a decision on whether to merge this with this issue remaining (but clearly stated as a doc comment) or take some other action.

[samueltardieu]

note: I'd like to hear what the reviewers think about this issue, i.e., since I think this is usually a (very) minor issue, I'd like a decision on whether to merge this with this issue remaining (but clearly stated as a doc comment) or take some other action.

This is so niche that I don't think it can block the patch (unless there is a very easy solution to fix this aesthetic issue).