compiler panic "randomly" with incremental build

[xNxExOx]

error: internal compiler error: src\librustc\ty\query\plumbing.rs:1195: Cannot force dep node: coherent_trait(core[b9cc]::ops[0]::drop[0]::Drop[0])

thread 'rustc' panicked at 'Box<Any>', src\librustc_errors\lib.rs:635:9
stack backtrace:
   0: std::sys_common::alloc::realloc_fallback
   1: std::panicking::take_hook
   2: std::panicking::take_hook
   3: <syntax::attr::builtin::IntType as rustc::ty::util::IntTypeExt>::disr_incr
   4: std::panicking::rust_panic_with_hook
   5: <rustc_errors::snippet::Style as core::fmt::Debug>::fmt
   6: rustc_errors::Handler::bug
   7: rustc::util::bug::bug_fmt
   8: <&rustc::mir::interpret::allocation::Allocation as rustc::ty::context::Lift>::lift_to_tcx
   9: <&rustc::mir::interpret::allocation::Allocation as rustc::ty::context::Lift>::lift_to_tcx
  10: <&rustc::mir::interpret::allocation::Allocation as rustc::ty::context::Lift>::lift_to_tcx
  11: rustc::util::bug::bug_fmt
  12: rustc::util::bug::bug_fmt
  13: rustc::ty::query::plumbing::force_from_dep_node
  14: rustc::dep_graph::graph::DepGraph::try_mark_green
  15: rustc::dep_graph::graph::DepGraph::try_mark_green
  16: rustc::dep_graph::graph::DepGraph::try_mark_green
  17: rustc::dep_graph::graph::DepGraph::try_mark_green
  18: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::try_print_query_stack
  19: rustc::traits::query::dropck_outlives::<impl rustc::infer::at::At>::dropck_outlives
  20: <rustc_typeck::impl_wf_check::ImplWfCheck as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_item
  21: <rustc_typeck::check::regionck::RegionCtxt as rustc::hir::intravisit::Visitor>::visit_expr
  22: <rustc_typeck::check::regionck::RegionCtxt as rustc::hir::intravisit::Visitor>::visit_expr
  23: <rustc_typeck::outlives::explicit::ExplicitPredicatesMap as core::fmt::Debug>::fmt
  24: <rustc_typeck::check::Diverges as core::fmt::Debug>::fmt
  25: <rustc_typeck::check::regionck::RegionCtxt as rustc::hir::intravisit::Visitor>::visit_expr
  26: <rustc_typeck::check::Diverges as core::fmt::Debug>::fmt
  27: <rustc_typeck::check::regionck::RegionCtxt as rustc::hir::intravisit::Visitor>::visit_expr
  28: <rustc_typeck::outlives::explicit::ExplicitPredicatesMap as core::fmt::Debug>::fmt
  29: rustc_typeck::check::regionck::<impl rustc_typeck::check::FnCtxt>::regionck_fn
  30: <rustc_typeck::check::Diverges as core::fmt::Debug>::fmt
  31: <rustc_typeck::check::CheckItemTypesVisitor as rustc::hir::itemlikevisit::ItemLikeVisitor>::visit_item
  32: rustc::infer::unify_key::<impl ena::unify::UnifyKey for rustc::ty::sty::FloatVid>::index
  33: rustc::dep_graph::graph::DepGraph::assert_ignored
  34: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::try_print_query_stack
  35: rustc::ty::query::plumbing::force_from_dep_node
  36: rustc::dep_graph::graph::DepGraph::try_mark_green
  37: rustc::dep_graph::graph::DepGraph::try_mark_green
  38: rustc::dep_graph::graph::DepGraph::try_mark_green
  39: rustc::dep_graph::graph::DepGraph::try_mark_green
  40: rustc::dep_graph::graph::DepGraph::try_mark_green_and_read
  41: <rustc_typeck::collect::find_existential_constraints::ConstraintLocator as rustc::hir::intravisit::Visitor>::visit_trait_item
  42: rustc_typeck::check_crate
  43: rustc_interface::passes::BoxedResolver::to_expansion_result
  44: rustc_driver::set_sigpipe_handler
  45: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
  46: <env_logger::fmt::WriteStyle as core::default::Default>::default
  47: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
  48: rustc_driver::set_sigpipe_handler
  49: rustc_interface::interface::Compiler::output_file
  50: rustc_driver::set_sigpipe_handler
  51: rustc_driver::set_sigpipe_handler
  52: <env_logger::filter::inner::Filter as core::fmt::Display>::fmt
  53: <rustc_driver::Compilation as core::fmt::Debug>::fmt
  54: rustc_driver::set_sigpipe_handler
  55: _rust_maybe_catch_panic
  56: rustc_driver::set_sigpipe_handler
  57: <std::error::<impl core::convert::From<alloc::string::String> for alloc::boxed::Box<dyn +std::error::Error+core::marker::Sync+core::marker::Send>>::from::StringError as core::fmt::Display>::fmt
  58: std::sys::windows::thread::Thread::new
  59: BaseThreadInitThunk
  60: RtlUserThreadStart
query stack during panic:
#0 [dropck_outlives] computing dropck types for `Canonical { max_universe: U0, variables: [CanonicalVarInfo { kind: Region(U0) }], value: ParamEnvAnd { param_env: ParamEnv { caller_bounds: [Binder(TraitPredicate(<T as std::marker::Send>)), Binder(TraitPredicate(<T as my::prelude::ConnectionLike>)), Binder(TraitPredicate(<T as my::connection_like::ConnectionLike>)), Binder(TraitPredicate(<P as std::marker::Send>)), Binder(TraitPredicate(<P as my::prelude::Protocol>)), Binder(TraitPredicate(<P as my::queryable::Protocol>)), Binder(TraitPredicate(<TupleType as std::marker::Send>)), Binder(TraitPredicate(<TupleType as my::prelude::FromRow>)), Binder(TraitPredicate(<P as std::marker::Sized>)), Binder(TraitPredicate(<T as std::marker::Sized>)), Binder(TraitPredicate(<TupleType as std::marker::Sized>)), Binder(OutlivesPredicate(T, ReLateBound(DebruijnIndex(1), BrAnon(0)))), Binder(OutlivesPredicate(P, ReLateBound(DebruijnIndex(1), BrAnon(0)))), Binder(OutlivesPredicate(TupleType, ReLateBound(DebruijnIndex(1), BrAnon(0))))], reveal: UserFacing, def_id: None }, value: std::result::Result<std::vec::Vec<TupleType>, my::error::Error> } }`
#1 [typeck_tables_of] processing `get_all_results`
#2 [analysis] running analysis passes on this crate
end of query stack

note: rustc 1.35.0-nightly (acd8dd6a5 2019-04-05) running on x86_64-pc-windows-msvc
note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib

It have something to do with incremental build :( query stack seems to point to random function sometimes even in file that was not edited for weeks. Issue started today. Deleting target folder help for few compilations.
I do not use latest compiler because some problems with crate upgrades and incompatibilities with async/await! so the issue is not caused by the compiler version, because I use same version for a while, but it is triggered by something in my code.

Is there anything I can look for in my code that could cause these issues?

[hellow554]

Remember what you've done between cleaning and ICEing. (maybe auto git commit every save or similar ^^).
In my case it was just renaming a variable from map to Map which causes an ICE.

[xNxExOx]

when I think backward 🤔
it first appeared when I add crate slotmap, and with that crate I was able to reproduce it even with 2 lines edit to their simplest example, so at that point I think it is caused by the crate and removed it and it was fine for a while, I chose to use CHashMap that solve some problems for me.
🤔 I can not say after which change it reappear.

[xNxExOx]

https://docs.rs/slotmap/0.3.0/slotmap/macro.new_key_type.html

new_key_type! {
    //struct EntityKey;

    /// Key for the Player slot map.
    pub struct PlayerKey;
}
new_key_type! {
    pub struct MyKey;
}

fn main() {
    let mut players = SlotMap::with_key();
    let mut entities: SlotMap<MyKey, (f64, f64)> = SlotMap::with_key();
    let bob: PlayerKey = players.insert("bobby");
    // Now this is a type error because entities.get expects an EntityKey:
    // entities.get(bob);
}

I want to know if I could use u32 as key because I already have unique u32 so I try to implement Key trait for struct containing only u32 get error, so I tried to replace their key and still get the error, and when I commented out //struct EntityKey; it compile, I tried few other combinations, but compiler panicked a lot, so I decided it is not the crate I want and removed it prom my project.

[nikomatsakis]

triage:

I'm going to mark this as P-high, but it might be more of a "medium" bug. It's a bit hard to say. I think there are few bits of info that would be useful:

• First and foremost, a more concrete recipe for reproducing the problem, ideally with a standalone example
• Second, some idea if this is a regression -- did the problem only start recently?

[xNxExOx]

For the first question:
I am on windows 10 Pro 1809, CPU 1950X, 64 GB RAM and steps to reproduce are simple for me:

• start IntelliJ IDEA
• new rust project
• to Cargo.toml add slotmap = "0.3.0"
• replace main.rs with

#[macro_use]
extern crate slotmap;

use slotmap::SlotMap;

new_key_type! {
    struct EntityKey;

    /// Key for the Player slot map.
    pub struct PlayerKey;
}

fn main() {
    let mut players = SlotMap::with_key();
    let mut entities: SlotMap<EntityKey, (f64, f64)> = SlotMap::with_key();
    let bob: PlayerKey = players.insert("bobby");
    // Now this is a type error because entities.get expects an EntityKey:
    // entities.get(bob);
}

• build
• add MyKey as mentioned above
• build ~50% chance it fail
• if the build worked just rename MyKey
• build failed 5 of 6 times I get that far without deleting target folder

For the second question yes it started recently when I tried this crate, but more importantly the issue persisted after I removed it, it is just much less common than every second build.

[hellow554]

Sadly I cannot reproduce it. Let me try to summarize it:

1. cargo new bar
2. add sloptmap = "0.3.0" as dependency in Cargo.toml
3. use

#[macro_use]
extern crate slotmap;

use slotmap::SlotMap;

new_key_type! {
    struct EntityKey;

    /// Key for the Player slot map.
    pub struct PlayerKey;
}

fn main() {
    let mut players = SlotMap::with_key();
    let mut entities: SlotMap<EntityKey, (f64, f64)> = SlotMap::with_key();
    let bob: PlayerKey = players.insert("bobby");
    // Now this is a type error because entities.get expects an EntityKey:
    // entities.get(bob);
}

4. cargo build
5. use

#[macro_use]
extern crate slotmap;

use slotmap::SlotMap;

new_key_type! {
//    struct EntityKey;

    /// Key for the Player slot map.
    pub struct PlayerKey;
}

new_key_type! {
    pub struct MyKey;
}

fn main() {
    let mut players = SlotMap::with_key();
    let mut entities: SlotMap<MyKey, (f64, f64)> = SlotMap::with_key();
    let bob: PlayerKey = players.insert("bobby");
    // Now this is a type error because entities.get expects an EntityKey:
    // entities.get(bob);
}

5. cargo build (hope it crashes)
6. if not, use

#[macro_use]
extern crate slotmap;

use slotmap::SlotMap;

new_key_type! {
//    struct EntityKey;

    /// Key for the Player slot map.
    pub struct PlayerKey;
}

new_key_type! {
    pub struct MyKeY;
}

fn main() {
    let mut players = SlotMap::with_key();
    let mut entities: SlotMap<MyKeY, (f64, f64)> = SlotMap::with_key();
    let bob: PlayerKey = players.insert("bobby");
    // Now this is a type error because entities.get expects an EntityKey:
    // entities.get(bob);
}

Am I correct? Please be as precice as possible and clarify "just rename MyKey". Do you want me to change lower/upper case? Remove one character? Add one?

Your nightly seems kind of outdated. Is it still possible for you if you use the latest nightly? (I tried both, no luck)

[hellow554]

🎉 It seems that it has been fixed on latest nightly, but I'm now able to reproduce it 100% with nightly-2019-04-05 (acd8dd6).

1. cargo new project
2. add sloptmap = "0.3.0" as dependency in Cargo.toml
3. use

#[macro_use]
extern crate slotmap;

use slotmap::SlotMap;

new_key_type! {
//    struct EntityKey;
    pub struct PlayerKey;
}

fn main() {}

4. cargo build
5. remove // in front of struct EntityKey
6. cargo build
7. add // in front of struct EntityKey again
8. 💥