ICE when building with --emit=mir

[iximeow]

This occurs on 1.34.1 and 1.34.0, is a regression from 1.33.0, and does.. not occur on nightly?

Reproduction:

pub fn main() {
    enum Inner { Member(u32) };
    Inner::Member(0);
}

compiled with RUST_BACKTRACE=1 rustc --emit=mir test.rs

Yields:

error: internal compiler error: src/librustc_mir/util/pretty.rs:612: Unexpected def description Some(Variant(DefId(0/1:9 ~ test[317d]::main[0]::Inner[0]::Member[0])))

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:620:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:70
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:58
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:482
   6: std::panicking::begin_panic
   7: rustc_errors::Handler::bug
   8: rustc::util::bug::opt_span_bug_fmt::{{closure}}
   9: rustc::ty::context::tls::with_opt::{{closure}}
  10: rustc::ty::context::tls::with_context_opt
  11: rustc::ty::context::tls::with_opt
  12: rustc::util::bug::opt_span_bug_fmt
  13: rustc::util::bug::bug_fmt
  14: rustc_mir::util::pretty::write_mir_intro
  15: rustc_mir::util::pretty::write_mir_pretty
  16: rustc_mir::transform::dump_mir::emit_mir
  17: rustc_driver::driver::compile_input::{{closure}}
  18: <std::thread::local::LocalKey<T>>::with
  19: rustc::ty::context::TyCtxt::create_and_enter
  20: rustc_driver::driver::compile_input
  21: rustc_driver::run_compiler_with_pool
  22: <scoped_tls::ScopedKey<T>>::set
  23: rustc_driver::run_compiler
  24: syntax::with_globals
  25: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  26: <F as alloc::boxed::FnBox<A>>::call_box
  27: std::sys::unix::thread::Thread::new::thread_start
             at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/liballoc/boxed.rs:759
             at src/libstd/sys_common/thread.rs:14
             at src/libstd/sys/unix/thread.rs:81
  28: start_thread
  29: clone
query stack during panic:
end of query stack
error: aborting due to previous error

I found this in building crates like cc and num-derive but pared it down to this

[iximeow]

I think this is fixed in 3a83cb2#diff-730459e7733d29bbbb60bd1962bf1842 which might explain why it doesn't occur on nightly

[pnkfelix]

triage: Probably fixed by #59036. Normally an ICE would lead me to tag this as P-high, but the fact that this is only exposed by --emit=mir leads me to prioritize this as P-medium.

[pnkfelix]

assigning to self to confirm that #59036 is the reason this is fixed, and (if need be) add a regression test.

[Ryan1729]

Here's a slightly smaller case of what appears to potentially be the same thing which shows up if you select the "show MIR" option in the Playground

enum E {
    V(())
}

pub fn main() {}

In particular the following error is observed:

error: internal compiler error: src/librustc_mir/util/pretty.rs:612: Unexpected def description Some(Variant(DefId(0/1:9 ~ playground[5604]::E[0]::V[0])))

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:620:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to previous error


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.34.2 (6c2484dc3 2019-05-13) running on x86_64-unknown-linux-gnu

note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type bin

note: some of the compiler flags provided by cargo are hidden

[osa1]

I think this issue is fixed in all channels. I tried stable and nightly both locally and on play.rust-lang.org, and couldn't get any ICEs.

Should we add a test? Otherwise we can just close I think.