rustc panicked at 'Metadata module not compiled?'

[RalfJung]

With the following code

#![allow(warnings)]

#[no_mangle]
fn main(){}

I sometimes get this error:

thread '<unnamed>' panicked at 'Metadata module not compiled?', src/libcore/option.rs:1038:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

When I run this many times on playground, the error comes and goes (just keep pressing "Run"). Seems to be some sort of race condition.

The backtrace is rather useless:

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::continue_panic_fmt
             at src/libstd/panicking.rs:385
   7: rust_begin_unwind
             at src/libstd/panicking.rs:312
   8: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   9: core::option::expect_failed
             at src/libcore/option.rs:1038
query stack during panic:
end of query stack

[tesuji]

On rustc stable on x86_64-linux-gnu and rustc 1.35.0-nightly (cb2f34d 2019-03-22).

Edit: Also on rustc +nightly-2019-04-07-x86_64-unknown-linux-gnu

 % rustc check.rs 
error: entry symbol `main` defined multiple times
 --> check.rs:4:1
  |
4 | fn main(){}
  | ^^^^^^^^^^^
  |
  = help: did you use #[no_mangle] on `fn main`? Use #[start] instead

error: aborting due to previous error

[RalfJung]

How often have you tried running this? I don't get the error every time.

[tesuji]

Edit: I tested both cases: set and unset RUSTC_WRAPPER.
I ran until cargo +nightly run --release --verbose; do cargo clean; done in around 30 seconds.
In all cases I don't see any errors like you.

[RalfJung]

The following testcases needed normalization in #59769 because I witnessed them being affected by this:

src/test/ui/duplicate/dupe-symbols-7.rs
src/test/ui/huge-array-simple.rs
src/test/ui/huge-array.rs
src/test/ui/huge-struct.rs
src/test/ui/issues/issue-15919.rs
src/test/ui/issues/issue-17913.rs
src/test/ui/issues/issue-56762.rs
src/test/ui/linkage2.rs
src/test/ui/linkage3.rs

I am not sure what to do with this, but there is a pattern: all of them either have some linkage-related problems or a "too big type". Funny enough, I have not seen huge-enum fail yet, but maybe that is just random chance?

EDIT: huge-enum failed on CI.

[bjorn3]

Does this still happen?

[RalfJung]

We still have the test normalization in place in a couple tests (grep for Metadata module not compiled). So -- maybe. You can try removing this from all tests and we'll see if the panic still occurs.

[saethlin]

We haven't seen any breakage since merging the above PR that removes the normalization, so I think whatever the root cause was here has been fixed.