Compiler crashes after changing Deleting a Trait implemented and referenced by a struct

[Koettlitz]

neurons.rs.txt
The attached file is the only file of the project that really contains source code, except the lib.rs.
My code included a Trait Neuron, that was implemented for Struct FurtherNeuron. FurtherNeuron had a field of type Option<Vec<Rc<RefCell<&dyn Neuron>>>> and some methods dealing with that field. I compiled it only with cargo build and everything was fine.
I then restructured my code as follows:
I removed Trait Neuron, renamed the struct FurtherNeuron to "Neuron" and changed the mentioned field to type Option<Vec<Rc<RefCell<Neuron>>>>. Calling cargo build again with RUST_BACKTRACE=1 set printed the following output:

Compiling neurons v0.1.0 (/home/david/rust/workspace/neurons)
error: internal compiler error: src/librustc/dep_graph/graph.rs:680: DepNode Hir(neurons[f81f]::neurons[0]::Neuron[0]::id[0]) should have been pre-allocated but wasn't.

thread 'rustc' panicked at 'Box', src/librustc_errors/lib.rs:905:9
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:84
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:61
4: core::fmt::write
at src/libcore/fmt/mod.rs:1025
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1426
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:65
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:50
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:193
9: std::panicking::default_hook
at src/libstd/panicking.rs:210
10: rustc_driver::report_ice
11: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:475
12: std::panicking::begin_panic
13: rustc_errors::HandlerInner::bug
14: rustc_errors::Handler::bug
15: rustc::util::bug::opt_span_bug_fmt::{{closure}}
16: rustc::ty::context::tls::with_opt::{{closure}}
17: rustc::ty::context::tls::with_opt
18: rustc::util::bug::opt_span_bug_fmt
19: rustc::util::bug::bug_fmt
20: rustc::dep_graph::graph::DepGraph::try_mark_previous_green
21: rustc::dep_graph::graph::DepGraph::try_mark_green
22: rustc::dep_graph::graph::DepGraph::try_mark_green_and_read
23: rustc::ty::query::plumbing::::get_query
24: <rustc_typeck::outlives::implicit_infer::InferVisitor as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_item
25: rustc::hir::Crate::visit_all_item_likes
26: rustc_typeck::outlives::inferred_outlives_crate
27: rustc::ty::query::__query_compute::inferred_outlives_crate
28: rustc::dep_graph::graph::DepGraph::with_task_impl
29: rustc::ty::query::plumbing::::get_query
30: rustc_typeck::outlives::inferred_outlives_of
31: rustc::ty::query::::compute
32: rustc::dep_graph::graph::DepGraph::with_task_impl
33: rustc::ty::query::plumbing::::force_query
34: rustc::ty::query::plumbing::force_from_dep_node
35: rustc::dep_graph::graph::DepGraph::try_mark_previous_green
36: rustc::dep_graph::graph::DepGraph::try_mark_previous_green
37: rustc::dep_graph::graph::DepGraph::try_mark_green
38: rustc::dep_graph::graph::DepGraph::try_mark_green_and_read
39: rustc::ty::query::plumbing::::get_query
40: <rustc_typeck::collect::CollectItemTypesVisitor as rustc::hir::intravisit::Visitor>::visit_item
41: rustc::hir::map::Map::visit_item_likes_in_module
42: rustc_typeck::collect::collect_mod_item_types
43: rustc::ty::query::__query_compute::collect_mod_item_types
44: rustc::ty::query::::compute
45: rustc::dep_graph::graph::DepGraph::with_task_impl
46: rustc::ty::query::plumbing::::get_query
47: rustc::ty::query::plumbing::::ensure_query
48: rustc_typeck::check_crate::{{closure}}::{{closure}}
49: rustc::util::common::time
50: rustc_typeck::check_crate
51: rustc_interface::passes::analysis
52: rustc::ty::query::__query_compute::analysis
53: rustc::dep_graph::graph::DepGraph::with_task_impl
54: rustc::ty::query::plumbing::::get_query
55: rustc::ty::context::tls::enter_global
56: rustc_interface::interface::run_compiler_in_existing_thread_pool
57: std::thread::local::LocalKey::with
58: scoped_tls::ScopedKey::set
59: syntax::with_globals
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose 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.41.0 (5e1a799 2020-01-27) running on x86_64-unknown-linux-gnu

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

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

query stack during panic:
#0 [type_of] processing neurons::Neuron::id
#1 [inferred_outlives_crate] computing the inferred outlives predicates for items in this crate
#2 [inferred_outlives_of] processing neurons::NeuronCore
#3 [predicates_of] processing neurons::NeuronCore
#4 [collect_mod_item_types] collecting item types in module neurons
#5 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to previous error

error: could not compile neurons.

I don't know why the socks appear in the compiler message line 15, 18 and 19. Can't see or mark them in the source of this text. Hope this helps you find/fix the bug :)

[pnkfelix]

Hmm I had thought we specifically fixed the bug here, via PR #68289.

This bug is filed against rustc 1.41.0 (5e1a799 2020-01-27). PR #68289 landed on the January 28 nightly.

My suspicion is that the problem won't produce on the beta or nightly branches.

(However, I don't know if we would want to backport PR #68289 to the stable branch...)

[Koettlitz]

Oh right, with the beta version it compiles. Thanks

[pnkfelix]

okay I'm going to close this as fixed (in beta, at least).

Or at least, I do not think the problem at hand warrants a backport of PR #68289 to the stable branch (and subsequent point release).

[pnkfelix]

(thanks for the bug report, by the way! It is rare, but always appreciated, to see incremental bugs that actually have enough info to reproduce the issue.)