Internal compiler error on nightly: 'index out of bounds'

[avl]

I just got an internal compiler error. This happened after introducing a custom derive macro and using it on several structs. I'll try to narrow it down more, and will comment on this report if I make any progress.

Version

rustc 1.26.0-nightly (2789b067d 2018-03-06)
binary: rustc
commit-hash: 2789b067da2ac921b86199bde21dd231ace1da39
commit-date: 2018-03-06
host: x86_64-unknown-linux-gnu
release: 1.26.0-nightly
LLVM version: 6.0

Backtrace

thread 'rustc' panicked at 'index out of bounds: the len is 241450 but the index is 241450', /checkout/src/libcore/slice/mod.rs:871:14
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 libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:207
   3: std::panicking::default_hook
             at libstd/panicking.rs:223
   4: core::ops::function::Fn::call
   5: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:403
   6: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:349
   7: rust_begin_unwind
             at libstd/panicking.rs:325
   8: core::panicking::panic_fmt
             at libcore/panicking.rs:72
   9: core::panicking::panic_bounds_check
             at libcore/panicking.rs:58
  10: rustc::dep_graph::graph::DepGraph::with_task_impl
  11: rustc::ty::maps::<impl rustc::ty::maps::queries::crate_disambiguator<'tcx>>::force
  12: rustc::ty::maps::<impl rustc::ty::maps::queries::crate_disambiguator<'tcx>>::try_get
  13: rustc::ty::maps::TyCtxtAt::crate_disambiguator
  14: rustc::ty::maps::on_disk_cache::OnDiskCache::compute_cnum_map::{{closure}}::{{closure}}
  15: <std::collections::hash::map::HashMap<K, V, S> as core::iter::traits::Extend<(K, V)>>::extend
  16: rustc::dep_graph::graph::DepGraph::with_ignore
  17: rustc::ty::maps::on_disk_cache::OnDiskCache::load_diagnostics
  18: rustc::dep_graph::graph::DepGraph::try_mark_green
  19: rustc::ty::maps::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::try_mark_green_and_read
  20: rustc::ty::maps::<impl rustc::ty::maps::queries::target_features_enabled<'tcx>>::try_get
  21: rustc::ty::maps::TyCtxtAt::target_features_enabled
  22: <rustc::hir::check_attr::CheckAttrVisitor<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_item
  23: rustc::hir::check_attr::check_crate
  24: rustc::ty::context::TyCtxt::create_and_enter
  25: rustc_driver::driver::compile_input
  26: rustc_driver::run_compiler

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.26.0-nightly (2789b067d 2018-03-06) running on x86_64-unknown-linux-gnu

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

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

error: Could not compile `fractal`.

To learn more, run the command again with --verbose.

[avl]

Using:

CARGO_INCREMENTAL=0 cargo build

instead of just cargo build, seems to resolve the problem.

[avl]

My program isn't correct, so I guess the problem is with some kind of diagnostics.

[avl]

Ok, now that I've fixed the compilation errors, the program compiles ok with CARGO_INCREMENTAL=0 . It even appears to run correctly, but it still cannot be recompiled with CARGO_INCREMENTAL=1 .

It can be compiled with CARGO_INCREMENTAL=0
It can be compiled once (after "cargo clean"), with CARGO_INCREMENTAL=1
Subsequent compiles with CARGO_INCREMENTAL=1 crash, even after a whitespace-only change.

[avl]

Ok, another lead: I was using my 'savefile' crate (which is on crates.io) with its custom-derive macro to derive an implementation of a trait called Serialize .I was also, in the crate which would not compile, using serde to derive its trait called Serialize. These are different traits. Perhaps the incremental compilation could not keep these two apart somehow? My immediate problem is solved, since I was trying out both serde and savefile, and never intended to actually use both simultaneously.

[Ameobea]

I've got the same problem in a crate I'm developing. I'm also using serde and serde-derive. The error only seems to occur after a compilation fails due to type error or similar. Deleting the target/debug/incremental directory allow the crate to compile successfully.

[ExpHP]

This is tagged A-type-system, but #49065 shows another instance of this bug that crashed during trans. The common factor between the two is an index error in DepGraph, which can be resolved by disabling incremental compilation.

[michaelwoerister]

This looks indeed like a problem with incremental compilation.

[ExpHP]

@jjl @avl @Ameobea since the crash seems to at least be deterministic, can anyone share the code that reproduces the crash? (minimizing it would be a huge help as well, but simply having anything would be great at this point)

Barring that, you can also help by testing other nightlies to pinpoint when the problem first started occurring. (you can do rustup override set nightly-YYYY-MM-DD to use a nightly from a specific day)