thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', compiler/rustc_middle/src/ty/query/mod.rs:235:5

[bjorn3]

Code

This happened while working on cg_clif.

Meta

rustc --version --verbose:

rustc 1.50.0-nightly (f4db9ffb2 2020-12-02)
binary: rustc
commit-hash: f4db9ffb22dfcb702dbdb2e0607cb91791866b57
commit-date: 2020-12-02
host: x86_64-unknown-linux-gnu
release: 1.50.0-nightly

Error output

   Compiling rustc_codegen_cranelift v0.1.0 (/home/bjorn/Documenten/cg_clif3)
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', compiler/rustc_middle/src/ty/query/mod.rs:235:5
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f4db9ffb22dfcb702dbdb2e0607cb91791866b57/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/f4db9ffb22dfcb702dbdb2e0607cb91791866b57/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/f4db9ffb22dfcb702dbdb2e0607cb91791866b57/library/core/src/panicking.rs:50:5
   3: rustc_middle::ty::query::try_load_from_on_disk_cache
   4: rustc_query_system::dep_graph::graph::DepGraph<K>::exec_cache_promotions
   5: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
   6: rustc_incremental::persist::save::save_in
   7: rustc_data_structures::sync::join
   8: rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::with_deps
   9: rustc_incremental::persist::save::save_dep_graph
  10: rustc_codegen_ssa::base::finalize_tcx
  11: rustc_codegen_ssa::base::codegen_crate
  12: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
  13: rustc_interface::queries::Queries::ongoing_codegen
  14: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  15: rustc_span::with_source_map
  16: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 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.50.0-nightly (f4db9ffb2 2020-12-02) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z run_dsymutil=no -C opt-level=3 -C embed-bitcode=no -C incremental -C link-arg=-Wl,-rpath=$ORIGIN/../lib --crate-type dylib

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

query stack during panic:
end of query stack
thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `LLVMing`,
 right: `Codegenning`', /rustc/f4db9ffb22dfcb702dbdb2e0607cb91791866b57/compiler/rustc_codegen_ssa/src/back/write.rs:1425:21
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f4db9ffb22dfcb702dbdb2e0607cb91791866b57/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/f4db9ffb22dfcb702dbdb2e0607cb91791866b57/library/core/src/panicking.rs:92:14
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 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.50.0-nightly (f4db9ffb2 2020-12-02) running on x86_64-unknown-linux-gnu

note: compiler flags: -Z run_dsymutil=no -C opt-level=3 -C embed-bitcode=no -C incremental -C link-arg=-Wl,-rpath=$ORIGIN/../lib --crate-type dylib

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

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

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

[bjorn3]

Removing the incremental cache fixed the issue.

[bjorn3]

Just saw this again.

[bjorn3]

I have hit this like 10 times now.

[wesleywiser]

Would you be able to push your changes to a branch or tag so we can try to repro? Thanks!

[bjorn3]

This is bjorn3/rustc_codegen_cranelift@d95d03a with the following patch:

diff --git a/src/lib.rs b/src/lib.rs
index ba9ee0d..82a88b1 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -204,11 +204,7 @@ fn codegen_crate<'tcx>(
         metadata: EncodedMetadata,
         need_metadata_module: bool,
     ) -> Box<dyn Any> {
-        let res = driver::codegen_crate(tcx, metadata, need_metadata_module, self.config);
-
-        rustc_symbol_mangling::test::report_symbol_names(tcx);
-
-        res
+        driver::codegen_crate(tcx, metadata, need_metadata_module, self.config)
     }
 
     fn join_codegen(
@@ -229,8 +225,6 @@ fn link(
     ) -> Result<(), ErrorReported> {
         use rustc_codegen_ssa::back::link::link_binary;
 
-        let _timer = sess.prof.generic_activity("link_crate");
-
         sess.time("linking", || {
             let target_cpu = crate::target_triple(sess).to_string();
             link_binary::<crate::archive::ArArchiveBuilder<'_>>(

The first time I hit this I think it was with just that patch. I have been working on bytecodealliance/wasmtime#2403 though and patched cg_clif to use a local checkout. This is something like bytecodealliance/wasmtime@2fea300. I don't have any clear instructions to reproduce it, but I have seen it quite often today.

[poliorcetics]

The line in question is currently rustc_cached_queries!(try_load_from_on_disk_cache!);, removing cache seems like the recommandable workaround for now, as you said earlier.

[jyn514]

I ran into this running x.py clippy on 0ad3dce with clippy version clippy 0.0.212 (f4db9ff 2020-12-02).

[matthiaskrgr]

I see this on ci for my cargo-cache crate as well but I didn't manage to reproduce locally yet.

EDIT: rustc 1.50.0-nightly (6645da366 2020-12-01) seems to be the first affected nightly according to my ci-log

EDIT2: in the commit range between this one and previous nightly ( git log b7ebc6b0c..6645da366 --merges ), #74967 seems suspicious as it touches incremental compilation.