ice: delay span bug with mir-opt-level=3 on ./debuginfo/issue-57822.rs

[matthiaskrgr]

core reduced from src/test/debuginfo/issue-57822.rs

Code

#![feature(generators, generator_trait)]

fn main() {
    let mut y = 2;
    let _ = move || {
        y += 1;
        yield;
    };
}

Meta

rustc --version --verbose:
repo is @ 12112f4

rustc 1.45.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.45.0-dev
LLVM version: 9.0

Error output

error: internal compiler error: error during interning should later cause validation failure
 --> ./debuginfo/issue-57822.rs:5:13
  |
5 |       let _ = move || {
  |  _____________^
6 | |         y += 1;
7 | |         yield;
8 | |     };
  | |_____^

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:366:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

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

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.45.0-dev running on x86_64-unknown-linux-gnu

note: compiler flags: -Z mir-opt-level=3

Backtrace

error: internal compiler error: error during interning should later cause validation failure
 --> ./debuginfo/issue-57822.rs:5:13
  |
5 |       let _ = move || {
  |  _____________^
6 | |         y += 1;
7 | |         yield;
8 | |     };
  | |_____^

thread 'rustc' panicked at 'no errors encountered even though `delay_span_bug` issued', src/librustc_errors/lib.rs:366:17
stack backtrace:
   0:     0x7fc4f8619cf8 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd08e85f94cff0dfc
   1:     0x7fc4f8665c3c - core::fmt::write::h65255e7874586eb2
   2:     0x7fc4f8607a03 - std::io::Write::write_fmt::h0f5532d7e9b1f8b5
   3:     0x7fc4f85f5d05 - std::panicking::default_hook::{{closure}}::hf30497d1f1ca597f
   4:     0x7fc4f85f59ef - std::panicking::default_hook::h9e9a0711680f7c71
   5:     0x7fc4f9ed97c3 - rustc_driver::report_ice::hc9a5a2c7362b2aef
   6:     0x7fc4f85f63fd - std::panicking::rust_panic_with_hook::hf9e06a37c137122b
   7:     0x7fc4fde7180e - std::panicking::begin_panic::hc7d17c7405fb9c0b
   8:     0x7fc4fdea87de - <rustc_errors::HandlerInner as core::ops::drop::Drop>::drop::hd5ccfa036df5ac1f
   9:     0x7fc4f9f2a1e6 - core::ptr::drop_in_place::hda33d9e89afe90a0
  10:     0x7fc4f9f2e2c6 - <alloc::rc::Rc<T> as core::ops::drop::Drop>::drop::hceff97f53948c28f
  11:     0x7fc4f9eb4fdd - core::ptr::drop_in_place::h9501cad978164a35
  12:     0x7fc4f9ea6667 - rustc_interface::interface::run_compiler_in_existing_thread_pool::h8df263b11ffbea7e
  13:     0x7fc4f9ee687e - scoped_tls::ScopedKey<T>::set::h7a66d7257e3dea88
  14:     0x7fc4f9edfbc4 - rustc_ast::attr::with_globals::h603e348501a977e0
  15:     0x7fc4f9eee97f - std::sys_common::backtrace::__rust_begin_short_backtrace::hd8e84709527dcd40
  16:     0x7fc4f9f440ae - core::ops::function::FnOnce::call_once{{vtable.shim}}::h8e4a8f2b241e9104
  17:     0x7fc4f85fe5f8 - std::sys::unix::thread::Thread::new::thread_start::h294f0533d573419f
  18:     0x7fc4f832446f - start_thread
  19:     0x7fc4f84413d3 - clone
  20:                0x0 - <unknown>

error: internal compiler error: unexpected panic

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

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.45.0-dev running on x86_64-unknown-linux-gnu

note: compiler flags: -Z mir-opt-level=3

query stack during panic:
end of query stack

[matthiaskrgr]

This does not reproduce with

rustc 1.45.0-nightly (a74d1862d 2020-05-14)
binary: rustc
commit-hash: a74d1862d4d87a56244958416fd05976c58ca1a8
commit-date: 2020-05-14
host: x86_64-unknown-linux-gnu
release: 1.45.0-nightly
LLVM version: 9.0

though, so it's a very recent regression.

[matthiaskrgr]

src/test/ui/iterators/skip-count-overflow.rs

fn main() {
    let i = (0..usize::max_value()).chain(0..10).skip(usize::max_value());
    assert_eq!(i.count(), 10);
}

produces the same error it seems.