Improve behavior of IF_LET_RESCOPE around temporaries and place expressions

[compiler-errors]

Heavily reworks the IF_LET_RESCOPE to be more sensitive around 1. temporaries that get consumed/terminated and therefore should not trigger the lint, and 2. borrows of place expressions, which are not temporary values.

Fixes #137411

[compiler-errors]

cc @dingxiangfei2009 #107251 (and @jieyouxu who reviewed it)

[traviscross]

Looks good to me.

[steffahn]

The #137376 fix would need to be a bit restricted to limit false negatives.

If the if let … is not sufficiently non-nested, we need to consider that semantics where changed in two ways: the temporaries (in edition 2021) lived throughout the else, but also the whole if let … didn’t bound the temporaries, either!

E.g. wrapping a if let … else into another function calls:

#![warn(rust_2024_compatibility)]

struct Droppy(u16);
impl Drop for Droppy {
    fn drop(&mut self) {
        println!("drop(Droppy({}))", self.0)
    }
}

fn do_stuff_with(property: bool) {
    println!("do_stuff_with({property})");
}

fn main() {
    f1();
    f2();
}

fn f1() {
    println!("==================== f1 ====================");
    do_stuff_with(if let Some(_x) = Some(Droppy(1337)) {
        true
    } else {
        false
    });
}

fn f2() {
    println!("==================== f2 ====================");
    do_stuff_with(if let Some(_x) = Some((Droppy(42), Droppy(69)).0) {
        true
    } else {
        false
    });
}

2021:

 ==================== f1 ====================
 drop(Droppy(1337))
 do_stuff_with(true)
 ==================== f2 ====================
 drop(Droppy(42))
 do_stuff_with(true)
 drop(Droppy(69))

2024:

 ==================== f1 ====================
 drop(Droppy(1337))
 do_stuff_with(true)
 ==================== f2 ====================
 drop(Droppy(42))
 drop(Droppy(69))
 do_stuff_with(true)

At least in the second case, there’s still a temporary left that escapes the if let.

And if the pattern does not consume the contents of the Some the effects are even more significant, e.g. replacing Some(x_) with Some(_):
2021:

 ==================== f1 ====================
 do_stuff_with(true)
 drop(Droppy(1337))
 ==================== f2 ====================
 do_stuff_with(true)
 drop(Droppy(42))
 drop(Droppy(69))

2024:

 ==================== f1 ====================
 drop(Droppy(1337))
 do_stuff_with(true)
 ==================== f2 ====================
 drop(Droppy(42))
 drop(Droppy(69))
 do_stuff_with(true)

so well… one could either conservatively trying to just keep the lint on all of these [of course currently, they are all linted], or trying to notice the specific un-problematic case.

Half of noticing the specific case was about whether there are any other temporaries around. Those are arguably still relevant even without any do_stuff_with wrapping, though! So I suppose these need handling, anyway…

fn f3() {
    if let Some(()) = (Droppy(123), None).1 {} else {
        println!("else {{\n    …\n}}");
    };
}

2021:

 else {
     …
 }
 drop(Droppy(123))

2024:

 drop(Droppy(123))
 else {
     …
 }

---

also compare the playground linked in #133753

[compiler-errors]

Ok, well I don't think #137376 is fixable in general given how little information we have in this point of the compiler about match exhaustivity and what temporaries have definitely been "accounted for" (i.e. moved or dropped).

The case of (...).field affects #137411 too, so I'll fix that, but I'll probably back out the last commit. Too bad!

[traviscross]

Perhaps you were already doing this, but it seems worthwhile to capture @steffahn's examples there as tests so that if someone tries again, we'll have to confront those.

[compiler-errors]

@steffahn is welcome to put up a separate PR to make them into tests.

[oli-obk]

@bors r+ rollup

[bors]

📌 Commit bad8e98 has been approved by oli-obk

It is now in the queue for this repository.