-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Description
When iterating over a collection, be it a Vec, a HashMap or an IndexMap, the order of items influences the value of the resulting hash: [a, b]
and [b, a]
have different hashes.
Meanwhile, there is some information we do not want to track. This is the case of the value of LocalDefId
. Inserting a function in a file will change other functions LocalDefId
, but it will not change their DefPathHash
.
My concern is about controlling this information flow. In order to do that ToStableHashKey
trait replaces the iteration order of the collection (which for hash maps is based on the key and the allocated memory capacity and should be irrelevant to the compilation), by the order of a stable hash key (the DefPathHash
when the key is LocalDefId
). By sorting the vectors by stable key, we manage the information flow.
Using IndexMap
, the iteration order is the insertion order. Normally, this insertion order should only depend on tracked information obtained by depending on another query. For instance, a HIR visitor will create a query dependency on hir_owner_nodes
, which hashes the in-code declaration order of functions. However, and this is my concern, the order of LocalDefId
is freely available without using a query and is purposely untracked.
In order to make IndexMap
s safe for incr. comp., we need to ensure untracked information is inaccessible.
Known issues:
- Stop implementing
PartialOrd
andOrd
onDefId
;Stop implementingPartialOrd
,Ord
andIdx
forLocalDefId
;Stop implementingPartialOrd
,Ord
andIdx
forLocalExpnId
;Stop implementingPartialOrd
andOrd
forSyntaxContext
;Enforce that UNTRACKED options are not accessed within a query.To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Originally posted by @cjgillot in #90253 (comment)
Activity
pierwill commentedon Oct 29, 2021
Can these items be done one at a time?
cjgillot commentedon Oct 29, 2021
Of course!
pierwill commentedon Oct 29, 2021
Will give this a go and see what happens. @rustbot claim
PartialOrd
,Ord
fromLocalDefId
#90408pierwill commentedon Oct 30, 2021
I started experimenting with
LocalDefId
. I wonder if theDefId
work might end up being slightly less complex. 🤔pierwill commentedon Nov 2, 2021
Update: No. 😄
pierwill commentedon Nov 3, 2021
Looks like removing
Ord
,PartialOrd
forExpnId
andLocalExpnId
might require changes to the macrorustc_index::newtype_index
because of this line:rust/compiler/rustc_index/src/vec.rs
Line 107 in 473eaa4
PartialOrd
/Ord
impls forDefId
andCrateNum
#83006bjorn3 commentedon Nov 5, 2021
Most of them are already "tracked" by discarding the entire incr comp cache if they change. The ones that aren't tracked are explicitly not tracked. See the
UNTRACKED
mentions in https://github.com/rust-lang/rust/blob/d22dd65835190278f315e06442614142653ec98f/compiler/rustc_session/src/options.rs A couple of them should be marked asTRACKED
though I think.pierwill commentedon Nov 8, 2021
115 remaining items