ICE `librustc_mir/monomorphize/collector.rs:776:` Cannot create local mono-item for DefId

[bjc]

Rust nightly: % rustc --version
rustc 1.36.0-nightly (6d59933 2019-04-22)

% RUST_BACKTRACE=1 cargo run
   Compiling intfn6 v0.1.0 (/home/bjc/src/MyStuff/intfn6)
error: internal compiler error: src/librustc_mir/monomorphize/collector.rs:776: Cannot create local mono-item for DefId(11/0:10 ~ intfn6[c1a9]::{{impl}}[0]::default_handler[0])

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:636: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 src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   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::monomorphize::collector::should_monomorphize_locally
  15: rustc_mir::monomorphize::collector::visit_instance_use
  16: <rustc_mir::monomorphize::collector::MirNeighborCollector as rustc::mir::visit::Visitor>::visit_terminator_kind
  17: rustc_mir::monomorphize::collector::collect_items_rec
  18: rustc_mir::monomorphize::collector::collect_items_rec
  19: rustc_mir::monomorphize::collector::collect_crate_mono_items::{{closure}}
  20: rustc::util::common::time
  21: rustc_mir::monomorphize::collector::collect_crate_mono_items
  22: rustc::util::common::time
  23: rustc_mir::monomorphize::partitioning::collect_and_partition_mono_items
  24: rustc::ty::query::__query_compute::collect_and_partition_mono_items
  25: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::collect_and_partition_mono_items>::compute
  26: rustc::dep_graph::graph::DepGraph::with_task_impl
  27: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  28: rustc_codegen_ssa::base::codegen_crate
  29: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::codegen_crate
  30: rustc::util::common::time
  31: rustc_interface::passes::start_codegen
  32: rustc::ty::context::tls::enter_global
  33: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  34: rustc_interface::passes::create_global_ctxt::{{closure}}
  35: rustc_interface::passes::BoxedGlobalCtxt::enter
  36: rustc_interface::queries::Query<T>::compute
  37: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::ongoing_codegen
  38: rustc_interface::interface::run_compiler_in_existing_thread_pool
  39: std::thread::local::LocalKey<T>::with
  40: scoped_tls::ScopedKey<T>::set
  41: syntax::with_globals
query stack during panic:
#0 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
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.36.0-nightly (6d599337f 2019-04-22) running on x86_64-unknown-linux-gnu

note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin

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

error: Could not compile `intfn6`.

To learn more, run the command again with --verbose.
[1]    9047 exit 101   RUST_BACKTRACE=1 cargo run

Test code attached: intfn6.zip

[bjc]

This panic did not occur when all code was combined into a single main.rs. It occurred as I moved code from main.rs into a new lib.rs, as it is in the attched .zip file.

[pnkfelix]

triage: P-high due to ICE; removing nomination tag.

[davidtwco]

Update (pnkfelix): the reproduction posted on this comment (see below) no longer reproduces the bug with the currently nightly (perhaps due to a papering-over of the issue mentioned below).

---

You can reproduce the issue with this test:

// src/test/ui/issue-60363.rs
// aux-build:issue-60363.rs

extern crate issue_60363;

use issue_60363::Handler;

#[allow(dead_code)]
static HANDLER: Handler = Handler::new();

fn main() {}

// src/test/ui/auxiliary/issue-60363.rs
#![crate_type = "rlib"]
#![feature(const_fn)]

use std::cell::UnsafeCell;

pub struct Handler {
    h: UnsafeCell<*const dyn FnMut()>,
}

impl Handler {
    pub const fn new() -> Self {
        Self {
            h: UnsafeCell::new(&Self::default_handler),
        }
    }

    fn default_handler() {}
}

unsafe impl Sync for Handler {}

See this comment for an explanation of the ICE.

[oli-obk]

So... the &Self::default_handler creates a promoted (e.g. the same as what let _: &'static FnMut() = &main; does). That promoted is created during the compilation of the rlib. When we call Handler::new() in the binary, we essentially end up with a static memory location that refers to another static one (the promoted). When we are collecting all the memory of HANDLER we're recursing into all visible memory locations in order to collect all function pointers and similar. We don't have to do that here though, as the default_handler function pointer has already been collected in the lib crate.

We basically need to make sure that

rust/src/librustc_mir/monomorphize/collector.rs

Line 1193 in d65e721

Some(AllocKind::Memory(alloc)) => {

stops if it encounters an AllocId from a different crate, because there can't possibly be any items in there that haven't already been collected upstream.

I'm not sure how we should solve that though :/ We could start giving Allocations a DefId of the item that caused the Allocation to be created. Seems kind of heavy for such an issue, but it would also give us some more debugging capabilities when looking at Allocations.

[izderadicka]

FYI - hit this issue (or very similar) when using RLS with latest rust-websocket (however normal cargo build runs OK, only RLS has problems):

{"message":"src/librustc/ty/context.rs:565: node_type: no type for node `expr <Self>::FIN (id=24986)`","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":"error: internal compiler error: src/librustc/ty/context.rs:565: node_type: no type for node `expr <Self>::FIN (id=24986)`\n\n"}
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:643:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to previous error\n\n"}

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.36.0-nightly (d628c2e64 2019-05-05) running on x86_64-unknown-linux-gnu

note: compiler flags: -C debuginfo=2 --crate-type lib

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

[jonas-schievink]

@izderadicka no, that's an unrelated issue – see #59134

[oli-obk]

Is this issue still occurring?

rust/src/librustc_mir/monomorphize/collector.rs

Line 1205 in a6b5d22

if should_monomorphize_locally(tcx, &fn_instance) {

looks to me like we papered over the issue

[pnkfelix]

triage: Assigning to @oli-obk and self