-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-incr-compArea: Incremental compilationArea: Incremental compilationC-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Both DefId
and CrateNum
are not stable across compilation sessions - the associated DefPathHash
is a stable cross-session ID. However, both DefId
and CrateNum
have Ord
impls, which makes it easy to accidentally sort something by the unstable DefID
/CrateNum
value. If this sorted result makes its way into a query result, it can lead to unstable hash values across compilation sessions. See #82920 for an example of this occuring.
My initial attempt to remove these impls encountered a large number of usages across multiple crates.
Metadata
Metadata
Assignees
Labels
A-incr-compArea: Incremental compilationArea: Incremental compilationC-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
JohnTitor commentedon Jun 19, 2021
#85829 refactored
CrateNum
soDefId
is the only item here.Hmm, yes, for example, we use
DefId
withinBTreeMap
orFxHashMap
. So, is the rough fix to storeDefPathHash
instead of it?pierwill commentedon Nov 5, 2021
@rustbot claim
pierwill commentedon Nov 5, 2021
This issue is part of #90317.
pierwill commentedon Nov 5, 2021
@Aaron1011 Looks like we can close this in favor of #90317, yes?