If-Let-Else and Let-Else doesn't produce same result which creates UB.

[Azvanzed]

I tried this code:

static MUTEX: spin::Mutex<Option<fn()>> = spin::Mutex::new(None);

// SAMPLE A
fn main() {
    let Some(value) = *MUTEX.lock() else {
         unreachable!("Mutex not set");
     };

     value();
 }

// SAMPLE B
fn main() {
    if let Some(value) = *MUTEX.lock() {
        value();
    } else {
        unreachable!("Mutex not set");
    }
 }

I expected to see this happen:
A. calls the value function then the mutex unlocks. (IDA decompilation)

Instead, this happened:
B. mutex unlocks then calls the value function. (IDA decompilation)

Meta

The bug does occur in nightly.

rustc --version --verbose:

rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-pc-windows-msvc
release: 1.83.0
LLVM version: 19.1.1

Backtrace

Not needed since this is visible statically.

[traviscross]

This isn't a bug in rustc. In your code, since you didn't separately assign the mutex guard to some binding, it's just a temporary, and those don't generally outlive the statement in which they are created (with some caveats about tail expressions). See, e.g.:

• Add extensive set of drop order tests #133605

That said, we agree this is an unfortunate discrepancy between if-let and let-else, and it's something we're thinking about. If we were to change it (over an edition), it would likely be in the direction of making if-let more like let-else, i.e. continuing the direction we took in Rust 2024 to shorten the scope of temporaries.

In any event, it's probably advisable in cases like this to assign the mutex guard to a binding so as to be more explicit about the intended scope.

[Azvanzed]

Interesting; I've never looked at it this way but now that you've explained it it makes more sense.

Either way making it more similar to each other would be neat to avoid someone else falling in the same mistake i did.

Thanks!