-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
rustc: Remove HirId from queries #44435
Conversation
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
@@ -836,11 +836,11 @@ pub struct GlobalCtxt<'tcx> { | |||
// Records the free variables refrenced by every closure | |||
// expression. Do not track deps for this, just recompute it from | |||
// scratch every time. | |||
freevars: FxHashMap<HirId, Rc<Vec<hir::Freevar>>>, | |||
freevars: FxHashMap<DefId, Rc<Vec<hir::Freevar>>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe there's DefIdMap
and DefIdSet
aliases which could be used for these changes.
let hir_id = self.hir.node_to_hir_id(fid); | ||
match self.freevars(hir_id) { | ||
let def_id = self.hir.local_def_id(fid); | ||
match self.freevars(def_id) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So with_freevars
used to be a thing because of a RefCell
. Can it be removed in favor of tcx.freevars(def_id)
? All callers should, ironically, already have a closure DefId
around.
Could not compile
|
☔ The latest upstream changes (presumably #44335) made this pull request unmergeable. Please resolve the merge conflicts. |
Thanks, @alexcrichton! Unfortunately it won't be as easy as just replacing impl TyCtxt {
fn in_scope_traits_of_expr(self, hir_id: HirId) -> Option<Rc<Vec<TraitCandidate>>> {
// Get the map for the item containing the HirId. This is a query:
let map_for_containing_item = self.in_scope_traits_of_item(hir_id.owner);
// From that item-local map get actual return value
map_for_containing_item.get(hir_id.local_id).cloned()
}
} |
Heh yeah the panics figured that out pretty quickly here! I'll work on making these sub-maps. |
14c68ee
to
7e49951
Compare
Alright I believe the necessary maps have been transitioned, re-r? @michaelwoerister |
src/librustc/dep_graph/dep_node.rs
Outdated
@@ -570,8 +570,8 @@ define_dep_nodes!( <'tcx> | |||
[] UsedCrateSource(CrateNum), | |||
[] PostorderCnums, | |||
|
|||
[] Freevars(HirId), | |||
[] MaybeUnusedTraitImport(HirId), | |||
[] Freevars(DefIndex), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use DefId
here? Closures have DefId
s.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed! Got a bit overzealous with DefIndex
7e49951
to
7666583
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me except for that one performance concern.
src/librustc_metadata/cstore_impl.rs
Outdated
let id = tcx.hir.definitions().find_node_for_hir_id(id); | ||
assert_eq!(id.krate, LOCAL_CRATE); | ||
let hir_id = tcx.hir.definitions().def_index_to_hir_id(id.index); | ||
let id = tcx.hir.definitions().find_node_for_hir_id(hir_id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops, I should better have listened to @arielb1 and marked find_node_for_hir_id
as super-slow somehow. It does a linear search over all NodeIds 😰
But it seems that what you're doing here is equivalent to tcx.hir.as_local_node_id(id).unwrap()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does find_node_for_hir_id
exist? I've introduced hir_to_node_id
. (EDIT: I generated a reverse HashMap
for that purpose)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see. It does exist because I wanted to avoid building that reverse mapping because it was only needed in error reporting. It's probably cheap to build though, especially now that locals don't have DefIds anymore.
7666583
to
772ca85
Compare
@bors: r=michaelwoerister |
📌 Commit 772ca85 has been approved by |
This'll allow us to reconstruct query parameters purely from the `DepNode` they're associated with. Some queries could move straight to `HirId` but others that don't always have a correspondance between `HirId` and `DefId` moved to two-level maps where the query operates over a `DefIndex`, returning a map, which is then keyed off `ItemLocalId`. Closes rust-lang#44414
772ca85
to
caaf365
Compare
@bors: r=michaelwoerister |
📌 Commit caaf365 has been approved by |
rustc: Remove HirId from queries This'll allow us to reconstruct query parameters purely from the `DepNode` they're associated with. Closes #44414
☀️ Test successful - status-appveyor, status-travis |
This'll allow us to reconstruct query parameters purely from the
DepNode
they're associated with.
Closes #44414