`must_not_suspend` should trigger for temporary in match expression (but does not)

[qutesy]

I tried this code:

#![feature(must_not_suspend)]
#![deny(must_not_suspend)]

use std::cell::RefCell;

struct S (RefCell<Inner>);

struct Inner {
}

impl Inner {
    async fn do_stuff(&self) {
        futures::future::ready(()).await;
    }
}

#[tokio::main]
async fn main() {
    let s = S ( RefCell::new(Inner {}) );
    println!("OUTside of match");
    match s.0.borrow_mut().do_stuff().await {
        () => {
          // The next line `panic()`-s.
          s.0.borrow_mut();
          println!("INside of match")
        }
    };
}

I expected to see this happen: compile-time error. Something like

error: `RefMut` held across a suspend point, but should not be

Instead, this happened: run-time panic (see below)

Meta

rustc --version --verbose: nightly on playground (1.58.0-nightly, 2021-11-14 ad44239...)

Backtrace

thread 'main' panicked at 'already borrowed: BorrowMutError', src/main.rs:24:15
stack backtrace:
   0: rust_begin_unwind
             at /rustc/ad442399756573dccacb314b6bf8079964bcc72a/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/ad442399756573dccacb314b6bf8079964bcc72a/library/core/src/panicking.rs:106:14
   2: core::result::unwrap_failed
             at /rustc/ad442399756573dccacb314b6bf8079964bcc72a/library/core/src/result.rs:1613:5
   3: core::result::Result<T,E>::expect
             at /rustc/ad442399756573dccacb314b6bf8079964bcc72a/library/core/src/result.rs:1255:23
   4: core::cell::RefCell<T>::borrow_mut
             at /rustc/ad442399756573dccacb314b6bf8079964bcc72a/library/core/src/cell.rs:946:9
   5: playground::main::{{closure}}
             at ./src/main.rs:24:11
[...]

[qutesy]

Adding appropriate labels based on a similar bug. Apologies if I've got this incorrect!

@rustbot label: +A-lint +A-async-await

[tmandry]

Discussed in wg-async-foundations triage meeting. It's possible #91032 fixes this; we should add a test for this case if it does.

This doesn't necessarily need to block stabilizing the feature (cc #83310), but it would be really nice if we could fix it.