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).

[Nilstrieb]

@rustbot label +E-needs-mcve

[Nilstrieb]

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).

[Rageking8]

On a side note why is the let else label not delimited by a _ in the center, like the other feature labels?

[Rageking8]

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

The ICE can also be reproduced with cargo build as mentioned above, although only in release mode (for latest nightly, on playground). Not sure whether it is lint related or not.

[est31]

The ICE can also be reproduced with cargo build as mentioned above, although only in release mode (for latest nightly, on playground). Not sure whether it is lint related or not.

Oh it seems to issue the ICE if you are both in release mode and you use the "Build" feature of the playground. I've tried using the "Run" feature in release mode but it didn't issue the ICE. The playground changes automatically from "Run" to "Build" if you remove the main function, but in this instance I'd added a fn main() {} so it didn't change to "Build" for me. Interesting...

[dingxiangfei2009]

Interestingly dropping the async from fn run produces a correct MIR with -C opt-level=3. I am having a look.

@rustbot claim

[est31]

Okay I have locally applied #102257 and and the PR does not fix this issue, still there.

[est31]

FTR this is the test file I've used (might be helpful for @dingxiangfei2009 ):

// issue #102317
// run-pass
// compile-flags: --edition 2021 -C opt-level=3 -Zvalidate-mir

struct SegmentJob {
    spec: String,
}

pub async fn run() -> Result<(), ()> {
    let jobs = Vec::<SegmentJob>::new();
    let Some(job) = jobs.into_iter().next() else {
        return Ok(())
    };

    Ok(())
}

fn main() {}

[estebank]

Removing requires-nightly because it is reproducible in beta too, marking as beta regression so this doesn't accidentally slip into stable.

[dingxiangfei2009]

@est31 investigating unwind drops introduced by build_exit_tree. It looks terribly wrong. 🤔

[Nilstrieb]

This might be the same problem as #99852. I have looked into this before with @JakobDegen, which lead us to discover #100513. I have no idea what exactly is wrong in the code though, it's very complicated.

[Rageking8]

Removing requires-nightly because it is reproducible in beta too, marking as beta regression so this doesn't accidentally slip into stable.

Oops, accidentally added that. My bad.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high