-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
thread 'rustc' panicked at 'called Option::unwrap()
on a None
value', compiler/rustc_middle/src/ty/query/mod.rs:235:5
#79661
Comments
Removing the incremental cache fixed the issue. |
Just saw this again. |
I have hit this like 10 times now. |
Would you be able to push your changes to a branch or tag so we can try to repro? Thanks! |
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. |
The line in question is currently |
I ran into this running |
I see this on ci for my EDIT: EDIT2: in the commit range between this one and previous nightly ( |
I'm getting this on ykrustc too. We last synced with upstream rust on December 3rd. It only seems to happen on an incremental build (i.e. not on a fresh build). I was able to trigger the error by adding more and more |
cc @Aaron1011 It looks like we're seeing some regressions from #74967 |
I'm not able to reproduce this locally. @bjorn3 Could you try to write a script that reproduces this crash with |
@Aaron1011 can you reproduce it using clippy? #79661 (comment) |
I managed to reproduce this using cloud-hypervisor/cloud-hypervisor#2032 |
I've fixed the issue locally, and I'm working on a PR. |
Labelling |
…wesleywiser Properly re-use def path hash in incremental mode Fixes rust-lang#79661 In incremental compilation mode, we update a `DefPathHash -> DefId` mapping every time we create a `DepNode` for a foreign `DefId`. This mapping is written out to the on-disk incremental cache, and is read by the next compilation session to allow us to lazily decode `DefId`s. When we decode a `DepNode` from the current incremental cache, we need to ensure that any previously-recorded `DefPathHash -> DefId` mapping gets recorded in the new mapping that we write out. However, PR rust-lang#74967 didn't do this in all cases, leading to us being unable to decode a `DefPathHash` in certain circumstances. This PR refactors some of the code around `DepNode` deserialization to prevent this kind of mistake from happening again.
This avoids an incremental compilation bug fixed on nightly: rust-lang/rust#79661
Code
This happened while working on cg_clif.
Meta
rustc --version --verbose
:Error output
The text was updated successfully, but these errors were encountered: