false positive for `if-let-rescope` on enums when the pattern exhaustively matches all cases with significant-drop fields

[steffahn]

Coming from #133167 (comment) and from this new forum thread, my takeaway of some remaining clear false positives is:

• if the if let matches on an enum and only some enum variant(s) have fields with potentially-significant destructor, but those are exhaustively matched in the non-else case of the if let, then there can be no actual change in behavior, because the else case is only reached in case the drop is not significant

• in the case of cargo-edit, this was if let Some(…irrefutable…) = expr on an Option<T>

• in the urlo thread, I’ve identified the case of if let Err(…irrefutable…) on a Result<(), E>

Here’s a simple repro for an Option case:

Code

#![allow(unused)]
#![warn(if_let_rescope)]

struct Struct;
impl Drop for Struct {
    fn drop(&mut self) {}
}

fn f(option_s: Option<Struct>) {
    if let Some(s) = option_s {
        // …
    } else {
        // …
    }
}

Here’s the code in the playground.

Current output

warning: `if let` assigns a shorter lifetime since Edition 2024
  --> src/lib.rs:10:8
   |
10 |     if let Some(s) = option_s {
   |        ^^^^^^^^^^^^^^--------
   |                      |
   |                      this value has a significant drop implementation which may observe a major change in drop order and requires your discretion
   |
   = warning: this changes meaning in Rust 2024
   = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/temporary-if-let-scope.html>
help: the value is now dropped here in Edition 2024
  --> src/lib.rs:12:5
   |
12 |     } else {
   |     ^
note: the lint level is defined here
  --> src/lib.rs:2:9
   |
2  | #![warn(if_let_rescope)]
   |         ^^^^^^^^^^^^^^
help: a `match` with a single arm can preserve the drop order up to Edition 2021
   |
10 ~     match option_s { Some(s) => {
11 |         // …
12 ~     } _ => {
13 |         // …
14 ~     }}
   |

@rustbot label A-edition-2024, A-lints, L-if_let_rescope, C-enhancement

[traviscross]

cc @dingxiangfei2009 @nikomatsakis

[compiler-errors]

edit: nevermind

#137444 (namely, the last commit) should fix this case too, but it's pretty unclear without looking what ...irrefutable... is in the wild.

For now, all that PR does is fix the case where it's an enum variant on the LHS and all of the subpatterns are bindings (x) or wildcards (_). I didn't really want to go over the top and make the is_infallible conditional very complex, but I could refine it if we can boil this down to a few easy to characterize cases.