Compiler panics with "More than one activation introduced at the same location"

[justinmayhew]

Note: the code compiles successfully after turning the nll feature off.

After running rustup update to get the latest Nightly compiler, code that used to compile no longer compiles.

I tried this code: https://github.com/mayhewj/msh

I expected to see this happen: A successful compilation

Instead, this happened:

$ cargo build
   Compiling msh v0.1.0 (file:///home/justin/src/msh)
thread 'rustc' panicked at 'More than one activation introduced at the same location.', librustc_mir/dataflow/impls/borrows.rs:216:21

Meta

rustc --version --verbose:
rustc 1.27.0-nightly (637ac17 2018-04-03)
binary: rustc
commit-hash: 637ac17
commit-date: 2018-04-03
host: x86_64-unknown-linux-gnu
release: 1.27.0-nightly
LLVM version: 6.0

Backtrace:

stack backtrace:
   0:     0x7fb98eea381b - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::haf21fb2d1a534f52
                               at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:     0x7fb98ee71950 - std::sys_common::backtrace::print::h222ac106928ee2b8
                               at libstd/sys_common/backtrace.rs:71
                               at libstd/sys_common/backtrace.rs:59
   2:     0x7fb98ee9725d - std::panicking::default_hook::{{closure}}::ha0ec7d04c7618490
                               at libstd/panicking.rs:207
   3:     0x7fb98ee96fbb - std::panicking::default_hook::h94862576a4900944
                               at libstd/panicking.rs:223
   4:     0x7fb98b4e146d - core::ops::function::Fn::call::h7f5866913c0a5607
   5:     0x7fb98ee977a9 - std::panicking::rust_panic_with_hook::ha4fb1372609c4048
                               at libstd/panicking.rs:403
   6:     0x7fb98c0754a5 - std::panicking::begin_panic::h2b7788e9181b7095
   7:     0x7fb98c1a0d76 - <rustc_mir::dataflow::impls::borrows::Borrows::new::GatherBorrows<'a, 'gcx, 'tcx> as rustc::mir::visit::Visitor<'tcx>>::visit_assign::h35f9347a7832f8c4
   8:     0x7fb98c19f650 - rustc_mir::dataflow::impls::borrows::Borrows::new::h9c0408c0400a81c9
   9:     0x7fb98c0507d1 - rustc_mir::borrow_check::do_mir_borrowck::h47e6140075bc43eb
  10:     0x7fb98bfda0c8 - <std::thread::local::LocalKey<T>>::with::h6f6a4179110e7243
  11:     0x7fb98c0b4298 - rustc::ty::context::GlobalCtxt::enter_local::h6a5455630fef40da
  12:     0x7fb98c04f6bc - rustc_mir::borrow_check::mir_borrowck::hebec48d216acf899
  13:     0x7fb98b3fa43f - rustc::ty::maps::<impl rustc::ty::maps::queries::mir_borrowck<'tcx>>::compute_result::he167f10bbbb61ef0
  14:     0x7fb98b081500 - rustc::dep_graph::graph::DepGraph::with_task_impl::h26e8e7cd35f6e0c6
  15:     0x7fb98b0e88dc - rustc_errors::Handler::track_diagnostics::h0169b067a940efbb
  16:     0x7fb98b3488a7 - rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::cycle_check::h5f78a4f3ed5ba6ff
  17:     0x7fb98b3fa4d6 - rustc::ty::maps::<impl rustc::ty::maps::queries::mir_borrowck<'tcx>>::force::h7c21a818484f92e3
  18:     0x7fb98b3fad70 - rustc::ty::maps::<impl rustc::ty::maps::queries::mir_borrowck<'tcx>>::try_get::h7511b02b472da79f
  19:     0x7fb98b3a904e - rustc::ty::maps::TyCtxtAt::mir_borrowck::h5cc03182edce72e1
  20:     0x7fb98b3a57f8 - rustc::ty::maps::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::mir_borrowck::h7fad85c586aefb83
  21:     0x7fb98f2358e3 - rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}::{{closure}}::hc73ec1e4941c1f93
  22:     0x7fb98f2a965a - <std::thread::local::LocalKey<T>>::with::h4190da1571fbd5ee
  23:     0x7fb98f2ad256 - <std::thread::local::LocalKey<T>>::with::h8b90a925ea17281a
  24:     0x7fb98f3210ae - rustc::ty::context::TyCtxt::create_and_enter::hf44c69229c58e5c3
  25:     0x7fb98f21b217 - rustc_driver::driver::compile_input::h01406b737f8d9fb7
  26:     0x7fb98f2ce36f - rustc_driver::run_compiler_impl::h72592b1443483e40
  27:     0x7fb98f2183c8 - syntax::with_globals::h861641f6eadc73c4
  28:     0x7fb98f2364dd - std::sys_common::backtrace::__rust_begin_short_backtrace::hce542848eb39a647
  29:     0x7fb98eeb1e7e - __rust_maybe_catch_panic
                               at libpanic_unwind/lib.rs:102
  30:     0x7fb98f24230d - <F as alloc::boxed::FnBox<A>>::call_box::h9ee6f2e4318cb3c5
  31:     0x7fb98eea8f07 - std::sys_common::thread::start_thread::h4e87150995e528f2
                               at /checkout/src/liballoc/boxed.rs:794
                               at libstd/sys_common/thread.rs:24
  32:     0x7fb98ee77f78 - std::sys::unix::thread::Thread::new::thread_start::h77e7f544c30e5001
                               at libstd/sys/unix/thread.rs:90
  33:     0x7fb989233493 - start_thread
  34:     0x7fb98eb63ace - __clone
  35:                0x0 - <unknown>

error: internal compiler error: unexpected panic

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.27.0-nightly (637ac17c5 2018-04-03) 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 `msh`.

[Osspial]

Getting this same error when compiling the derin_core crate, here: https://github.com/Osspial/derin/tree/ice_iv/derin_core. This appears to have been introduced between the 2018-04-02 and 2018-04-03 versions, as the error doesn't happen on the previous version.

Disabling nlls also fixes the ICE in my case, although it leads to other compiler errors due to the lack of non-lexical lifetimes.

[est31]

Also reported in #49662

[est31]

Thanks to the regression tool cargo-bisect-rustc I've found the regression to be in commit b12af86 PR #49348. cc @bobtwinkles @nikomatsakis

[sapphire-arches]

Ah, I think I know what happened here. Prior to #49348 only one thing could be activated at a given location. However, multiple reborrows activate at the same time when function calls are made. There are two possible fixes:

1. Make activation_map store a set of activated borrows.
2. Only create two-phase enabled reborrows for the method receiver.

I think we're probably going to have to do (1) at some point anyway, it's probably the less invasive change, and I'm not fully convinced we can do (2) in a general way. I should have a patch in for this before tomorrow morning baring unforseen complications in the implementation.