Internal compiler error with cargo run and cargo build

[jakobrs]

Code

This stops happening if I delete the target/debug/incremental directory.
This repository: https://gitlab.com/tasbot/tasbot_pbn
tar.gz of repository: tasbot_pbn.1.tar.gz

Meta

rustc --version --verbose:

rustc 1.55.0 (c8dfcfe04 2021-09-06)
binary: rustc
commit-hash: c8dfcfe046a7680554bf4eb612bad840e7631c4b
commit-date: 2021-09-06
host: x86_64-unknown-linux-gnu
release: 1.55.0
LLVM version: 12.0.1

Error output

~/projects/tasbot_pbn % cargo run
   Compiling textwrap v0.11.0
   Compiling proc-macro-error-attr v1.0.4
   Compiling proc-macro-error v1.0.4
   Compiling atty v0.2.14
   Compiling clap v2.33.3
   Compiling structopt-derive v0.4.16
   Compiling structopt v0.3.23
   Compiling tasbot-display v0.1.0 (https://github.com/jakobrs/tasbot-display.git?rev=499f086#499f0868)
   Compiling tasbot_pbn v0.1.0 (/home/user/projects/tasbot_pbn)
thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `124275628959117022`,
 right: `1002111927320821928687967599834759150`', compiler/rustc_query_impl/src/on_disk_cache.rs:692:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

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/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.55.0 (c8dfcfe04 2021-09-06) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type bin

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

query stack during panic:
end of query stack
error: could not compile `tasbot_pbn`

Backtrace

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `124275628959117022`,
 right: `1002111927320821928687967599834759150`', compiler/rustc_query_impl/src/on_disk_cache.rs:692:5
stack backtrace:
   0: rust_begin_unwind
             at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/panicking.rs:515:5
   1: core::panicking::panic_fmt
             at /rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/panicking.rs:92:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
   4: <rustc_query_impl::on_disk_cache::OnDiskCache as rustc_middle::ty::context::OnDiskCache>::new
   5: rustc_interface::passes::create_global_ctxt
   6: rustc_interface::queries::Queries::global_ctxt
   7: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
   8: rustc_span::with_source_map
   9: rustc_interface::interface::create_compiler_and_run
  10: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[apiraino]

@jakobrs can you reproduce this even after a cargo clean? I've tried compiling, cleaning, compiling and recompiling again with stable 1.55 but I failed to reproduce. Do you have some steps to help make this error reproducible? Thanks!

[jakobrs]

It happens if I run cargo build, but not if I run cargo clean followed by cargo build. But it does happen every time I run cargo build so long as I don't run cargo clean once.

I have no idea how I got the target directory into this state, though.

[nazar-pc]

It crashes in CI with cargo clippy and cargo test with clean builds with https://github.com/subspace/subspace as of commit 5f167155bfadeff9f8c873bdb013bb535d7fb5b8 (CARGO_INCREMENTAL=0), example: https://github.com/subspace/subspace/actions/runs/1289269998

It is a bad example probably as it is a big project and takes a long time to compile.

[apiraino]

@jakobrs checkin in for this issue. Did you have a chance to test against the latest 1.58.x stable?
@nazar-pc your CI seems not to break anymore on this issue, am I understanding this correctly?

Apologies for the long silence and thanks to both for a feedback!

@rustbot label +s-waiting-on-author

[nazar-pc]

Yes, a lot of things has changed since September though.

[jakobrs]

I ran cargo build on the unzipped archive and did not get an error, but it decided to recompile everything, so I'm not sure if this actually means anything.

I have no idea if it is possible to reliably get the build directory into this state where cargo build causes an ICE.

[apiraino]

I'm going to remove the I-prioritize label as this issue seems to have become harder to reproduce (might also be a candidate for being closed if no more evidence emerge). In case, don't hesitate to raise the flag.

@rustbot label -I-prioritize -s-waiting-on-author

[kpreid]

Triage: Relabeling issues which don't have a runnable reproduction (as opposed to having a non-minimized one) to the new label S-needs-repro.
@rustbot label +S-needs-repro -E-needs-mcve