Cannot create local mono-item for DefId

[bobbobbio]

The following scenario used to work fine 1.25.0:

echo '
pub fn hello_world()
{
    println!("hello world");
}
' > bar.rs
echo '
extern crate bar;

pub fn foo()
{
    bar::hello_world();
}
' > foo.rs
rustc --crate-type rlib --emit metadata bar.rs
rustc --crate-type rlib --emit llvm-bc bar.rs
rustc --crate-type rlib --emit llvm-bc foo.rs -L .

This would create two .bc files that could be linked together into a program, but when I try this on 1.26.{0,1,2} the compiler crashes like so:

error: internal compiler error: librustc_mir/monomorphize/collector.rs:746: Cannot create local mono-item for DefId(11/0:3 ~ bar[8787]::hello_world[0])

thread 'rustc' panicked at 'Box<Any>', librustc_errors/lib.rs:543:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:207
   3: std::panicking::default_hook
             at libstd/panicking.rs:223
   4: core::ops::function::Fn::call
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:403
   6: std::panicking::begin_panic
   7: rustc_errors::Handler::bug
   8: rustc::session::opt_span_bug_fmt::{{closure}}
   9: rustc::ty::context::tls::with_opt::{{closure}}
  10: <std::thread::local::LocalKey<T>>::try_with
  11: <std::thread::local::LocalKey<T>>::with
  12: rustc::ty::context::tls::with
  13: rustc::ty::context::tls::with_opt
  14: rustc::session::opt_span_bug_fmt
  15: rustc::session::bug_fmt
  16: rustc_mir::monomorphize::collector::should_monomorphize_locally
  17: rustc_mir::monomorphize::collector::visit_instance_use
  18: <rustc_mir::monomorphize::collector::MirNeighborCollector<'a, 'tcx> as rustc::mir::visit::Visitor<'tcx>>::visit_terminator_kind
  19: rustc_mir::monomorphize::collector::collect_items_rec
  20: rustc_mir::monomorphize::collector::collect_crate_mono_items
  21: rustc::util::common::time
  22: rustc_trans::base::collect_and_partition_translation_items
  23: rustc::dep_graph::graph::DepGraph::with_task_impl
  24: rustc_errors::Handler::track_diagnostics
  25: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::cycle_check
  26: rustc::ty::maps::<impl rustc::ty::maps::queries::collect_and_partition_translation_items<'tcx>>::force
  27: rustc::ty::maps::<impl rustc::ty::maps::queries::collect_and_partition_translation_items<'tcx>>::try_get
  28: rustc::ty::maps::TyCtxtAt::collect_and_partition_translation_items
  29: rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::collect_and_partition_translation_items
  30: rustc_trans::base::trans_crate
  31: <rustc_trans::LlvmTransCrate as rustc_trans_utils::trans_crate::TransCrate>::trans_crate
  32: rustc::util::common::time
  33: rustc_driver::driver::phase_4_translate_to_llvm
  34: rustc_driver::driver::compile_input::{{closure}}
  35: <std::thread::local::LocalKey<T>>::with
  36: <std::thread::local::LocalKey<T>>::with
  37: rustc::ty::context::TyCtxt::create_and_enter
  38: rustc_driver::driver::compile_input
  39: rustc_driver::run_compiler_impl
  40: syntax::with_globals
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.26.2 (594fb253c 2018-06-01) running on x86_64-unknown-linux-gnu

note: compiler flags: --crate-type rlib

[peterhuene]

Possibly dupe/related to #50865?

[oli-obk]

Yea I think this is a dupe, handling over there

[bobbobbio]

The issue you mention seems to have something to do with impl trait (and looks like it goes away when the use is removed?) , whereas the issue I posted here crashes with even the simplest rust code. Are they really the same?

[oli-obk]

Hmm... you're right. I mean impl Trait in the other issue is just the trigger, the cause is in a normal function calling another one, but here you have another crate

[bobbobbio]

I've discovered that if I tell the compiler to emit another type along with metadata like --emit=link,metadata this issue goes away. It makes me suspect this piece of code in librustc/session/config.rs:

    // True if any of the output types require codegen or linking.
    pub fn should_codegen(&self) -> bool {
        self.0.keys().any(|k| match *k {
            OutputType::Bitcode
            | OutputType::Assembly
            | OutputType::LlvmAssembly
            | OutputType::Mir
            | OutputType::Object
            | OutputType::Exe => true,
            OutputType::Metadata | OutputType::DepInfo => false,
        })
    }

I'm wondering if by not running the code-gen or linking when outputting the metadata is causing this.

[estebank]

Triage: still repros:

error: internal compiler error: src/librustc_mir/monomorphize/collector.rs:802: cannot create local mono-item for DefId(15:3 ~ bar[8787]::hello_world[0])

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:892:9
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: rustc_driver::report_ice
   6: std::panicking::rust_panic_with_hook
   7: std::panicking::begin_panic
   8: rustc_errors::HandlerInner::bug
   9: rustc_errors::Handler::bug
  10: rustc::util::bug::opt_span_bug_fmt::{{closure}}
  11: rustc::ty::context::tls::with_opt::{{closure}}
  12: rustc::ty::context::tls::with_context_opt
  13: rustc::ty::context::tls::with_opt
  14: rustc::util::bug::opt_span_bug_fmt
  15: rustc::util::bug::bug_fmt
  16: rustc_mir::monomorphize::collector::should_monomorphize_locally
  17: rustc_mir::monomorphize::collector::visit_instance_use
  18: <rustc_mir::monomorphize::collector::MirNeighborCollector as rustc::mir::visit::Visitor>::visit_terminator_kind
  19: rustc::mir::visit::Visitor::visit_body
  20: rustc_mir::monomorphize::collector::collect_items_rec
  21: rustc_mir::monomorphize::collector::collect_crate_mono_items::{{closure}}
  22: rustc::util::common::time
  23: rustc_mir::monomorphize::collector::collect_crate_mono_items
  24: rustc::util::common::time
  25: rustc_mir::monomorphize::partitioning::collect_and_partition_mono_items
  26: rustc::ty::query::__query_compute::collect_and_partition_mono_items
  27: rustc::dep_graph::graph::DepGraph::with_task_impl
  28: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  29: rustc_codegen_ssa::back::symbol_export::exported_symbols_provider_local
  30: rustc::ty::query::__query_compute::exported_symbols
  31: rustc::dep_graph::graph::DepGraph::with_task_impl
  32: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  33: rustc_metadata::rmeta::encoder::EncodeContext::encode_crate_root
  34: rustc::ty::context::tls::with_context::{{closure}}
  35: rustc_metadata::rmeta::encoder::encode_metadata
  36: rustc_metadata::rmeta::decoder::cstore_impl::<impl rustc::middle::cstore::CrateStore for rustc_metadata::creader::CStore>::encode_metadata
  37: rustc::ty::context::TyCtxt::encode_metadata
  38: rustc_interface::passes::encode_and_write_metadata
  39: rustc::util::common::time
  40: rustc_interface::passes::start_codegen
  41: rustc::ty::context::tls::enter_global
  42: rustc_interface::queries::Query<T>::compute
  43: rustc_interface::queries::Queries::ongoing_codegen
  44: rustc_interface::interface::run_compiler_in_existing_thread_pool
  45: std::thread::local::LocalKey<T>::with
  46: scoped_tls::ScopedKey<T>::set
  47: syntax::with_globals

[tmiasko]

Since #49433, rustc --emit=metadata doesn't include optimized MIR, so produced rlib cannot be used to perform codegen. It would be nice to detect that particular situtation and produce more meaningful error describing that this is unsupported.

[Enselic]

PR with fix: #115353