ICE: Broken MIR in Item(...) with `let_else` usage (use of local which has no storage here)

[fasterthanlime]

Reminiscent of #99975, which is now closed, but I'm able to reproduce it easily on today's nightly:

struct SegmentJob {
    spec: String,
}

pub async fn run() -> Result<(), ()> {
    let jobs = get_data();
    let Some(job) = jobs.into_iter().next() else {
        println!("no jobs!");
        return Ok(())
    };

    println!("should run job {}", job.spec);

    Ok(())
}

fn get_data() -> Vec<SegmentJob> {
    Default::default()
}

I expected to see this happen: typechecks fine.

Instead, this happened:

cargo clippy
    Checking broken-mir v0.1.0 (/home/amos/bearcove/broken-mir)
warning: Error finalizing incremental compilation session directory `/home/amos/bearcove/broken-mir/target/debug/incremental/broken_mir-3jg493t7jkrit/s-gdwtcmorgw-1apjoc8-working`: No such file or directory (os error 2)

error: internal compiler error: no errors encountered even though `delay_span_bug` issued

error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:7 ~ broken_mir[e8cc]::run::{closure#0}), const_param_did: None }) (after pass PhaseChange-Runtime(Optimized)) at bb29[0]:
                                use of local _21, which has no storage here
  --> src/lib.rs:10:6
   |
10 |     };
   |      ^
   |
   = note: delayed at compiler/rustc_const_eval/src/transform/validate.rs:128:36

thread 'rustc' panicked at 'Box<dyn Any>', compiler/rustc_errors/src/lib.rs:1530:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust-clippy/issues/new

note: Clippy version: clippy 0.1.65 (f5193a9 2022-09-25)

query stack during panic:
end of query stack
warning: `broken-mir` (lib) generated 1 warning
error: could not compile `broken-mir`; 1 warning emitted

Meta

rustc --version --verbose:

rustc 1.66.0-nightly (f5193a9fc 2022-09-25)
binary: rustc
commit-hash: f5193a9fcc73dc09e41a90c5a2c97fc9acc16032
commit-date: 2022-09-25
host: x86_64-unknown-linux-gnu
release: 1.66.0-nightly
LLVM version: 15.0.0

Backtrace

thread 'rustc' panicked at 'Box<dyn Any>', compiler/rustc_errors/src/lib.rs:1530:13
stack backtrace:
   0: std::panicking::begin_panic::<rustc_errors::ExplicitBug>
   1: std::panic::panic_any::<rustc_errors::ExplicitBug>
   2: <rustc_errors::HandlerInner as core::ops::drop::Drop>::drop
   3: core::ptr::drop_in_place::<rustc_session::parse::ParseSess>
   4: <alloc::rc::Rc<rustc_session::session::Session> as core::ops::drop::Drop>::drop
   5: core::ptr::drop_in_place::<rustc_interface::interface::Compiler>
   6: rustc_interface::interface::create_compiler_and_run::<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}>
   7: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_errors::ErrorGuaranteed>, rustc_driver::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_errors::ErrorGuaranteed>>

[fasterthanlime]

(I forgot to mention it in the original issue, but the let = if let Some(..) version of the code checks just fine).

[Noratrieb]

@rustbot label +E-needs-mcve

[Noratrieb]

Oh nvm this has an MCVE already lol
@rustbot label -E-needs-mcve

[fasterthanlime]

Oh nvm this has an MCVE already lol

Oh yeah this is the complete code - here's my repo for it, pinned toolchain and all: https://github.com/fasterthanlime/broken-mir

[est31]

The issue seems to not affect cargo build, but requires clippy instead... interesting.

[est31]

Given that it is both a scoping problem, and lint related, this might be fixed by #102257. If that PR is the fix, we should maybe backport it to beta.

cc @dingxiangfei2009

[Rageking8]

Tested it with the rust playground and was only able to get the ICE to trigger for release mode and not debug mode builds (current latest nightly).

@rustbot label +T-compiler +I-ICE +F-let-else +requires-nightly

[fasterthanlime]

Tested it with the rust playground and was only able to get the ICE to trigger for release mode and not debug mode builds (current latest nightly).

That's true for cargo build. cargo clippy always fails though (I'm not sure if --release does anything here).