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.

[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

[pnkfelix]

I am taking a break for a few months and I wont be able to look at this; unassigning self.

[pnkfelix]

@bjc can you confirm if this issue is still occurring for you?

[smokku]

This just happened to me.

{"message":"src/librustc/ty/context.rs:211: node type <B>::Item (hir_id=HirId { owner: DefIndex(246), local_id: 15 }) with HirId::owner DefId(0:246 ~ rayon[3c5a]::iter[0]::chain[0]::{{impl}}[2]::with_producer[0]::{{impl}}[0]) cannot be placed in TypeckTables with local_id_root DefId(0:238 ~ rayon[3c5a]::iter[0]::chain[0]::{{impl}}[2]::with_producer[0])","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":"error: internal compiler error: src/librustc/ty/context.rs:211: node type <B>::Item (hir_id=HirId { owner: DefIndex(246), local_id: 15 }) with HirId::owner DefId(0:246 ~ rayon[3c5a]::iter[0]::chain[0]::{{impl}}[2]::with_producer[0]::{{impl}}[0]) cannot be placed in TypeckTables with local_id_root DefId(0:238 ~ rayon[3c5a]::iter[0]::chain[0]::{{impl}}[2]::with_producer[0])\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.

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.39.0-nightly (7efe1c6e6 2019-09-17) 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

[senderista]

RLS is crashing on nightly 2019-09-22:

{"message":"src/librustc/ty/context.rs:211: node type <B>::Item (hir_id=HirId { owner: DefIndex(246), local_id: 15 }) with HirId::owner DefId(0:246 ~ rayon[b9e0]::iter[0]::chain[0]::{{impl}}[2]::with_producer[0]::{{impl}}[0]) cannot be placed in TypeckTables with local_id_root DefId(0:238 ~ rayon[b9e0]::iter[0]::chain[0]::{{impl}}[2]::with_producer[0])","code":null,"level":"error: internal compiler error","spans":[],"children":[],"rendered":"error: internal compiler error: src/librustc/ty/context.rs:211: node type <B>::Item (hir_id=HirId { owner: DefIndex(246), local_id: 15 }) with HirId::owner DefId(0:246 ~ rayon[b9e0]::iter[0]::chain[0]::{{impl}}[2]::with_producer[0]::{{impl}}[0]) cannot be placed in TypeckTables with local_id_root DefId(0:238 ~ rayon[b9e0]::iter[0]::chain[0]::{{impl}}[2]::with_producer[0])\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.

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.39.0-nightly (1dd188489 2019-09-22) running on x86_64-apple-darwin

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

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

{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to previous error\n\n"}

[pnkfelix]

assigning back to self for initial investigation

[pnkfelix]

The bug as encoded in the description of this bug appears to have been resolved sometime between nightly-2019-08-15 and nightly-2019-08-16:

% git log c43d03a19..f7af19c27 --format=oneline --author=bors
f7af19c279b8b7ea3d2c21fcbd67164af8d5d968 Auto merge of #63592 - Centril:rollup-7c6dg3e, r=Centril
1cdcea920e56a5d0587307a4c9cf8fff5c77c4bc Auto merge of #62429 - cuviper:iter-closures, r=cramertj
9e9a136fcec5eb78f09a14dfd072a51ae2550269 Auto merge of #63575 - Centril:rollup-anlv9g5, r=Centril
082cf2f9d136166cd1d552d3fb5abb1c46c99a14 Auto merge of #63534 - Mark-Simulacrum:stage0-bump, r=Centril
% 

[pnkfelix]

My bet is that the issue, as encoded in the description of this bug, was deliberately fixed (with appropriate matching test case), in PR #63582 (which was marked as fixing #63226) and was part of rollup PR #63592.

Closing as fixed.

(The other comments that mention similar problems should be filed as independent bugs, hopefully with more information such as links to source crates that replicate the issue, to allow us to actually investigate them.)

[alecmocatta]

I'm still getting an identical stack trace on my code on nightly-2019-11-06. My guess is it's perhaps inlining or some other heuristics that have been tweaked, masking the ICE of the original report.

error: internal compiler error: src/librustc_mir/monomorphize/collector.rs:806: Cannot create local mono-item for DefId(17:2303 ~ amadeus_parquet[2f0c]::internal[0]::record[0]::impls[0]::date_time_from_parquet[0])

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:931:9
stack backtrace:
   0:        0x111cbeb65 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0b2af991c2fe744d
   1:        0x111cf5cb0 - core::fmt::write::h9accbbe8984e0e42
   2:        0x111cb246b - std::io::Write::write_fmt::h043704431db5a03f
   3:        0x111cc2f73 - std::panicking::default_hook::{{closure}}::h6c92fb3ec83e7ead
   4:        0x111cc2c7a - std::panicking::default_hook::hc450333d5d96e7ef
   5:        0x10f16a012 - rustc_driver::report_ice::h0aa6b04ddcb1e761
   6:        0x111cc378c - std::panicking::rust_panic_with_hook::h917f6fb05cbf8c98
   7:        0x110cff621 - std::panicking::begin_panic::h1205e40bc9171afc
   8:        0x110d2c397 - rustc_errors::HandlerInner::bug::haeca66694c11cc59
   9:        0x110d2b28d - rustc_errors::Handler::bug::hb40f33537bef7c32
  10:        0x1105ed47b - rustc::util::bug::opt_span_bug_fmt::{{closure}}::h9f9613638d967607
  11:        0x1105eab36 - rustc::ty::context::tls::with_opt::{{closure}}::ha4d042d104651380
  12:        0x1105eaac4 - rustc::ty::context::tls::with_context_opt::h523faf69415e0011
  13:        0x1105eaaf2 - rustc::ty::context::tls::with_opt::h44fc742babe5f857
  14:        0x1105ed398 - rustc::util::bug::opt_span_bug_fmt::h8873c770af03df25
  15:        0x1105ed2eb - rustc::util::bug::bug_fmt::h1857b12f160422a8
  16:        0x10fbc6ec2 - rustc_mir::monomorphize::collector::should_monomorphize_locally::hd8019171dbcb3619
  17:        0x10fbc6b9b - rustc_mir::monomorphize::collector::visit_instance_use::he5c4d4b84a0d9240
  18:        0x10fbc6486 - <rustc_mir::monomorphize::collector::MirNeighborCollector as rustc::mir::visit::Visitor>::visit_terminator_kind::hf743bc76134dcb0a
  19:        0x10fbc4a93 - rustc_mir::monomorphize::collector::collect_items_rec::hfa14f1d35d76256f
  20:        0x10fbc53d2 - rustc_mir::monomorphize::collector::collect_items_rec::hfa14f1d35d76256f
  21:        0x10fbc53d2 - rustc_mir::monomorphize::collector::collect_items_rec::hfa14f1d35d76256f
  22:        0x10fbc53d2 - rustc_mir::monomorphize::collector::collect_items_rec::hfa14f1d35d76256f
  23:        0x10fbc53d2 - rustc_mir::monomorphize::collector::collect_items_rec::hfa14f1d35d76256f
  24:        0x10fbc53d2 - rustc_mir::monomorphize::collector::collect_items_rec::hfa14f1d35d76256f
  25:        0x10fa88fdd - rustc_mir::monomorphize::collector::collect_crate_mono_items::{{closure}}::h574170026231c7ac
  26:        0x10fa584f3 - rustc::util::common::time::hdca60068c42125a5
  27:        0x10fbc340f - rustc_mir::monomorphize::collector::collect_crate_mono_items::he0c4399775ba1745
  28:        0x10fa580a6 - rustc::util::common::time::h070e019f9ed47a1c
  29:        0x10fc7ebd4 - rustc_mir::monomorphize::partitioning::collect_and_partition_mono_items::hd2c425623409a37b
  30:        0x11438bf12 - rustc::ty::query::__query_compute::collect_and_partition_mono_items::hf7346204340bdd84
  31:        0x1143bc54a - rustc::dep_graph::graph::DepGraph::with_task_impl::h20d95ec042ad160d
  32:        0x11445c8d0 - rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query::hfb83f0160d8e8add
  33:        0x11449d24d - rustc_codegen_ssa::base::codegen_crate::h6850b2d17f847535
  34:        0x1144801a9 - <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::codegen_crate::hab30d48d4da2e9cd
  35:        0x10f233afe - rustc_interface::passes::start_codegen::{{closure}}::h6bcbe3d097a1e661
  36:        0x10f23bdac - rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}::h04e5fd864970b22a
  37:        0x10f27eeeb - rustc_interface::passes::create_global_ctxt::{{closure}}::h52bddd6fee95c3ac
  38:        0x10f239fc9 - rustc_interface::queries::Query<T>::compute::hede163aafb181870
  39:        0x10f24e04c - rustc_interface::queries::<impl rustc_interface::interface::Compiler>::ongoing_codegen::h485cc6931e7920e3
  40:        0x10f1a6d8f - rustc_interface::interface::run_compiler_in_existing_thread_pool::hea93b9ac2eadfbf3
  41:        0x10f189f44 - std::thread::local::LocalKey<T>::with::h7066d35c989f2793
  42:        0x10f188212 - scoped_tls::ScopedKey<T>::set::h34475cd5175c854c
  43:        0x10f1b2855 - syntax::with_globals::hf919ce8a65a9b30e
  44:        0x10f1c575d - std::sys_common::backtrace::__rust_begin_short_backtrace::h890ade53b1344e13
  45:        0x111cd2d1f - __rust_maybe_catch_panic
  46:        0x10f1c64c7 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hb7eb70cb9597c7f7
  47:        0x111ca4a0e - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h9b41d7adac010663
  48:        0x111cd1a5e - std::sys::unix::thread::Thread::new::thread_start::h0725fe9398379348
  49:     0x7fff5c8db2eb - _pthread_body
  50:     0x7fff5c8de249 - _pthread_start

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.40.0-nightly (1423bec54 2019-11-05) running on x86_64-apple-darwin

note: compiler flags: -C opt-level=3 --crate-type lib

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

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

[pnkfelix]

@alecmocatta

I already have done everything I can with the source code attached to this bug. Seeing analgous stack traces does not provide me with an alternative piece of source code to test and explore.

as previously noted in my closing comment:

(The other comments that mention similar problems should be filed as independent bugs, hopefully with more information such as links to source crates that replicate the issue, to allow us to actually investigate them.)