`-Zalways-encode-mir=yes` misses MIR for statics

[jsgf]

I tried this code:

foo.rs:

pub static FOO: &str = "foo";

pub fn foo() {
    println!("foo");
}

bar.rs:

pub fn bar() {
    println!("bar {}", foo::FOO);
    foo::foo();
}

rustc --crate-type rlib --crate-name foo -Crelocation-model=pic --edition=2018 foo.rs -Zalways-encode-mir=yes --emit metadata -o out/libfoo.rmeta
rustc --crate-type rlib --crate-name bar -Crelocation-model=pic --edition=2018 bar.rs --emit link=out/libbar.rlib --extern=foo=out/libfoo.rmeta

I expected to see this happen: generate libbar.rlib

Instead, this happened:

error: internal compiler error: compiler/rustc_mir/src/monomorphize/collector.rs:865:9: no MIR available for DefId(19:3 ~ foo[8787]::FOO)

thread 'rustc' panicked at 'Box<Any>', /rustc/9d9c2c92b834c430f102ea96f65119e37320776e/library/std/src/panic.rs:59:5
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/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.53.0-nightly (9d9c2c92b 2021-04-19) running on x86_64-unknown-linux-gnu

note: compiler flags: -C relocation-model=pic --crate-type rlib

query stack during panic:
#0 [collect_and_partition_mono_items] collect_and_partition_mono_items
#1 [exported_symbols] exported_symbols
end of query stack

Meta

rustc --version --verbose:

rustc 1.54.0-nightly (fe72845f7 2021-05-16)
binary: rustc
commit-hash: fe72845f7bb6a77b9e671e6a4f32fe714962cec4
commit-date: 2021-05-16
host: x86_64-unknown-linux-gnu
release: 1.54.0-nightly
LLVM version: 12.0.1

Backtrace

stack backtrace:
   0: std::panicking::begin_panic
   1: std::panic::panic_any
   2: rustc_errors::HandlerInner::bug
   3: rustc_errors::Handler::bug
   4: rustc_middle::ty::context::tls::with_opt
   5: rustc_middle::util::bug::opt_span_bug_fmt
   6: rustc_middle::util::bug::bug_fmt
   7: rustc_mir::monomorphize::collector::should_codegen_locally
   8: rustc_mir::monomorphize::collector::collect_miri
   9: <rustc_mir::monomorphize::collector::MirNeighborCollector as rustc_middle::mir::visit::Visitor>::visit_constant
  10: <rustc_mir::monomorphize::collector::MirNeighborCollector as rustc_middle::mir::visit::Visitor>::visit_rvalue
  11: rustc_mir::monomorphize::collector::collect_neighbours
  12: rustc_mir::monomorphize::collector::collect_items_rec
  13: rustc_session::utils::<impl rustc_session::session::Session>::time
  14: rustc_mir::monomorphize::collector::collect_crate_mono_items
  15: rustc_mir::monomorphize::partitioning::collect_and_partition_mono_items
  16: rustc_query_impl::<impl rustc_query_system::query::config::QueryAccessors<rustc_query_impl::plumbing::QueryCtxt> for rustc_query_impl::queries::collect_and_partition_mono_items>::compute
  17: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  18: rustc_data_structures::stack::ensure_sufficient_stack
  19: rustc_query_system::query::plumbing::force_query_with_job
  20: rustc_query_system::query::plumbing::get_query_impl
  21: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::collect_and_partition_mono_items
  22: rustc_codegen_ssa::back::symbol_export::exported_symbols_provider_local
  23: rustc_query_system::dep_graph::graph::DepGraph<K>::with_task_impl
  24: rustc_data_structures::stack::ensure_sufficient_stack
  25: rustc_query_system::query::plumbing::force_query_with_job
  26: rustc_query_system::query::plumbing::get_query_impl
  27: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::exported_symbols
  28: rustc_metadata::rmeta::encoder::EncodeContext::encode_crate_root
  29: rustc_metadata::rmeta::encoder::encode_metadata_impl
  30: rustc_data_structures::sync::join
  31: rustc_metadata::rmeta::decoder::cstore_impl::<impl rustc_middle::middle::cstore::CrateStore for rustc_metadata::creader::CStore>::encode_metadata
  32: rustc_middle::ty::context::TyCtxt::encode_metadata
  33: rustc_interface::passes::QueryContext::enter
  34: rustc_interface::queries::Queries::ongoing_codegen
  35: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  36: rustc_span::with_source_map
  37: rustc_interface::interface::create_compiler_and_run
  38: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[RalfJung]

This is strange, Miri uses -Zalways-encode-mir but statics seem to work fine for us?

[jsgf]

@RalfJung Does the test case I gave work for Miri?

I notice that -Zalways-encode-mir=yes produces much larger rmeta files than --emit metadata,link would, which are in turn larger than --emit metadata's rmetas (as expected).

It would be nice to have an option to make lone --emit metadata produce the same output as --emit metadata,link, and I was hoping that it would just be a matter of stabilizing -Zalways-encode-mir, but they don't seem to be equivalent. Ideally they'd produce the same output, but I'd be happy with functionally interchangable - which is what this issue is about.

Overall, I'm finding it hard to work out what controls what goes into a .rmeta file. I audited all the places where either or both of tcx.sess.opts.debugging_opts.always_encode_mir and/or opts.output_types.should_codegen() are checked, and unifying them does not produce an output where -Zalways-encode-mir=yes and --emit metadata together produce the same as metadata,link.

I guess I haven't confirmed that MIR is the only difference between the two cases.

[RalfJung]

Does the test case I gave work for Miri?

Yes: when I set up a 2-crate workspace matching your 2 files and then do cargo miri run, it works as expected.

[jsgf]

PR #85793 adds -Zmetadata-link so that --emit metadata generates equivalent rmetas to --emit metadata,link.