ICE: called Option::unwrap() on a None value at def_path_hash_map.rs:23:85
#107226
Labels
A-incr-comp
Area: Incremental compilation
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
|
(note: a |
|
From the report that cleaning solved, |
Noratrieb
added
the
T-compiler
|
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 38c47dfe3 to f8dec25bd. 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 68bdf609 to a4695788 this also happens on the most recent nightly i downloaded: Backtrace
to reproduce: |
jyn514
added
the
I-ICE
|
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 |
saethlin
changed the title
Option::unwrap() on a None value' at def_path_hash_map.rs:23:85
saethlin
changed the title
Option::unwrap() on a None value' at def_path_hash_map.rs:23:85Option::unwrap() on a None value at def_path_hash_map.rs:23:85
|
Reproduces on the latest nightly ( With the following starting code: pub enum GeneralConstId {
AnonymousConstId(u32),
}
pub struct HirDatabaseGroupStorage__ where Self: Send {
_key: <ConstEvalQuery as Query>::Key,
_value: Slot<ConstEvalQuery>,
}
pub trait Query {
type Key;
type Value;
}
pub struct ConstEvalQuery;
impl Query for ConstEvalQuery {
type Key = GeneralConstId;
type Value = &'static str;
}
pub struct Slot<Q: Query> {
_key: Q::Key,
_state: Q::Value,
}And the following change: pub enum GeneralConstId {
- AnonymousConstId(u32),
+ ConstBlockId(u32),
}Current error & backtrace: |
|
bisected with cargo-bisect-rustc v0.6.8 searched nightlies: nightly-2021-09-09 through nightly-2022-08-05 #82183 is likely where it regressed since it deals with EDIT: Thinking about it, that might just be where the issue was exposed since it shouldn't be touching that |
/// Extracts the DefId corresponding to this DepNode. This will work
/// if two conditions are met:
///
/// 1. The Fingerprint of the DepNode actually is a DefPathHash, and
/// 2. the item that the DefPath refers to exists in the current tcx.
///
/// Condition (1) is determined by the DepKind variant of the
/// DepNode. Condition (2) might not be fulfilled if a DepNode
/// refers to something from the previous compilation session that
/// has been removed.
fn extract_def_id(&self, tcx: TyCtxt<'_>) -> Option<DefId> {
if tcx.fingerprint_style(self.kind) == FingerprintStyle::DefPathHash {
Some(tcx.def_path_hash_to_def_id(
DefPathHash(self.hash.into()),
&("Failed to extract DefId", self.kind, self.hash),
))
} else {
None
}
} I have some code that panics around this area and I think that it is caused by #82183 as well. Comment suggest (2) that situation where |
pub trait P {
type A;
}
struct S;
impl P for S {
type A = C;
}
struct T<D: P>(D::A, Z<D>);
struct Z<D: P>(D::A, String);
impl<D: P> T<D> {
pub fn i() -> Self {
loop {}
}
}
enum C {
E(()),
}
pub fn m() {
T::<S>::i();
}compile, rename |
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Jun 21, 2024
Trying to address an incremental compilation issues This pull request contains two independent changes, one makes it so when `try_force_from_dep_node` fails to recover a query - it marks the node as "red" instead of "green" and the second one makes Debug impl for `DepNode` less panicky if it encounters something from the previous compilation that doesn't map to anything in the current one. I'm not 100% confident that this is the correct approach, but so far I managed to find a bunch of comments suggesting that some things are allowed to fail in a certain way and changes I made are allowing for those things to fail this way and it fixes all the small reproducers I managed to find. Compilation panic this pull request avoids is caused by an automatically generated code on an associated type and it is not happening if something else marks it as outdated first (or close like that, but scenario is quite obscure). Fixes rust-lang/rust#107226 Fixes rust-lang/rust#125367
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
reporting as requested.
RUST_BACKTRACE=1RUST_BACKTRACE=full:The text was updated successfully, but these errors were encountered: