Change:
/// has been removed. fn extract_def_id(&self, tcx: TyCtxt<'_>) -> Option<DefId> { if tcx.fingerprint_style(self.kind) == FingerprintStyle::DefPathHash { <del> Some(tcx.def_path_hash_to_def_id( DefPathHash(self.hash.into()), &("Failed to extract DefId", self.kind, self.hash), )) </del> <ins> tcx.def_path_hash_to_def_id(DefPathHash(self.hash.into())) </ins> } else { None }

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --The error cleared up when I cleared out /target/ and I couldn't make a minimal example, but I thought I'd post the panic message anyway in case its helpful. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
is that a... panic during a panic during a panic during a panic?
This specific panic should be fixed by along with some of the reasons to panic while panicking.
So I don't think there's anything else to do here but link and close the issue.

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Unfortunately this is nowhere near a minimal example, but it was a tricky one to figure out how to reliably reproduce. Here are the steps: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --This also happens with current nightly too: And here's the error from nightly: Unfortunately it's hard to say which version of Rust introduced this error since tracks the latest stable version of Rust. One possible way to narrow this down is that not all changes to the code seem to provoke the ICE. For example, if you checkout , do and then checkout and build that too, then it works fine. So I wonder if there is something about that is provoking the problem.
has an MSRV of 1.77 so I couldn't easily check how old this ICE is or bisect, but it happens on 1.77 as well. Finally, an incr-comp ICE with a repro <3
A repro with no external deps: to panics
rustc 1.80.0-nightly ( 2024-05-01) still crashes
duplicate of ?

reporting as requested. :
(note: a allowed compilation to succeed. I compile this multiple times a day and never run into this particular compilation problem, hence reporting)
From the report that cleaning solved, label +A-incr-comp
I also hit an ICE at the same line: Cleaning the tree also fixed it for me. I've saved a tarball of the tree (prior to cleaning) in case that helps, but it is too big to attach here. Let me know if you want it.
Also seen in: Seen when using incremental compilation of rust-analyzer, last compiled yesterday morning (2023-06-12) and today's evening (2023-06-13), going from commit to . I had cache previously, so I don't think this is simply one compilation that broke it but I'll have to check if I can reproduce
also managed to reproduce from compiling rust-analyzer, and managed to narrow down the range to going from to this also happens on the most recent nightly i downloaded: <details<summary<strongBacktrace</strong</summary<p</p</detailsto reproduce:
i got the same issue, same row and similar backtrace on Rust beta : a cargo clean also fix the issue
I saw this too: This is reproducible in my current state with . I've saved the full output and a ZFS snapshot of the current filesystem, which includes the source and target directories. If any of this is useful, let me know how to make it available. (It's about 80 GiB though.)
Reproduces on the latest nightly (). With the following starting code: And the following change: Current error & backtrace:
bisected with v0.6.8 searched nightlies: nightly-2021-09-09 through nightly-2022-08-05 regressed nightly: nightly-2021-09-19 regressed commit range:  commit list: is likely where it regressed since it deals with s. EDIT: Thinking about it, that might just be where the issue was exposed since it shouldn't be touching that in the first place.
I have some code that panics around this area and I think that it is caused by as well. Comment suggest (2) that situation where refers to something removed is possible and previously it would return , but after this mapping fails with panic.
compile, rename to , compile to get the panic.