-
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
HirId
-ification initiative
#50928
Comments
Thanks, @zackmdavis!
Yes, that's indeed what has been happening over the last year. We've done enough to make incremental compilation work and then pretty much stopped. Btw, it might be a good idea to add a custom implementation of impl Hash for HirId {
fn hash<H: Hasher>(&self, state: &mut H) {
let data: u64 = unsafe { mem::transmute(*self) };
state.write_u64(data);
}
} It would have to be tested if that actually speeds things up. |
Changing the `each_binding` utility method to take the `HirId` of a binding pattern rather than its `NodeId` seems like a modest first step in support of the `HirId`ification initiative rust-lang#50928. (The inspiration for choosing this in particular came from the present author's previous work on diagnostics issued during liveness analysis, which is the most greatly affected module in this change.)
…lwoerister operate on `HirId` instead of `NodeId` in `hir::Pat::each_binding`, and consequences of that See #50928 for motivation. Questions— * Is #50928 actually a good idea as a plan of record, or is there some reason to keep `NodeId`s? * Are the uses of `find_node_for_hir_id` in this initial submission OK (see the FIXME comments)? * Can we bikeshed a better method names `struct_span_lint_hir` _&c._? (Coined in analogy to the `struct_span_lint_node` and `NodeId`, but it feels kind of semantically clunky.) r? @michaelwoerister
Perhaps add tracking-issue label? |
For the HirIdification initiative rust-lang#50928.
For the HirIdification initiative rust-lang#50928.
HirId-ification, continued Another incremental step towards the vision of #50928 (previously: #50929). r? @michaelwoerister
I'm currently working on this. |
…, r=petrochenkov Remove remaining calls to `as_local_node_id` Split out from rust-lang#72552 cc rust-lang#50928
Once #72777 and #72781 have landed, In order to avoid re-introducing |
…f-id-from-node-id, r=petrochenkov rustdoc: remove calls to `local_def_id_from_node_id` rustdoc calls `local_def_id_from_node_id(CRATE_NODE_ID)` when it can just creates a top level `DefId` using `DefId::local(CRATE_DEF_INDEX)`. cc rust-lang#50928 r? @petrochenkov
…f-id-from-node-id, r=petrochenkov rustdoc: remove calls to `local_def_id_from_node_id` rustdoc calls `local_def_id_from_node_id(CRATE_NODE_ID)` when it can just creates a top level `DefId` using `DefId::local(CRATE_DEF_INDEX)`. cc rust-lang#50928 r? @petrochenkov
…str-path-error, r=petrochenkov Use `LocalDefId` instead of `NodeId` in `resolve_str_path_error` Together with rust-lang#72777 this should remove all uses of `NodeId` in `rustdoc`. cc rust-lang#50928 r? @petrochenkov
…str-path-error, r=petrochenkov Use `LocalDefId` instead of `NodeId` in `resolve_str_path_error` Together with rust-lang#72777 this should remove all uses of `NodeId` in `rustdoc`. cc rust-lang#50928 r? @petrochenkov
…=Xanewok save_analysis: work on HIR tree instead of AST In order to reduce the uses of `NodeId`s in the compiler, `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST. cc rust-lang#50928
…pis, r=ecstatic-morse Remove unsused `NodeId` related APIs in hir map cc rust-lang#50928 r? @ecstatic-morse
…pis, r=ecstatic-morse Remove unsused `NodeId` related APIs in hir map cc rust-lang#50928 r? @ecstatic-morse
…pis, r=ecstatic-morse Remove unsused `NodeId` related APIs in hir map cc rust-lang#50928 r? @ecstatic-morse
…def-id, r=petrochenkov Use `LocalDefId` directly in `Resolver::export_map` This is to avoid the final conversion from `NodeId` to `HirId` during call to `(clone|into)_outputs` This brings down the post-lowering uses of `NodeId` down to 2 calls to convert the `trait_map`. cc rust-lang#50928 r? @petrochenkov
…def-id, r=petrochenkov Use `LocalDefId` directly in `Resolver::export_map` This is to avoid the final conversion from `NodeId` to `HirId` during call to `(clone|into)_outputs` This brings down the post-lowering uses of `NodeId` down to 2 calls to convert the `trait_map`. cc rust-lang#50928 r? @petrochenkov
Small update:
I believe the solely remaining use of
I see two approaches to solve this:
What do you people think about all of this? |
…=petrochenkov Pre-compute `LocalDefId` <-> `HirId` mappings and remove `NodeId` <-> `HirId` conversion APIs cc rust-lang#50928 I don't know who is exactly the best person to review this. r? @petrochenkov
…=petrochenkov Pre-compute `LocalDefId` <-> `HirId` mappings and remove `NodeId` <-> `HirId` conversion APIs cc rust-lang#50928 I don't know who is exactly the best person to review this. r? @petrochenkov
Now that #73291 has landed, the table/map to convert Next step (and possibly final step?) is to move the remaining API's involving |
… r=petrochenkov Move remaining `NodeId` APIs from `Definitions` to `Resolver` Implements rust-lang#73291 (comment) TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed. After this, the only remaining work for rust-lang#50928 should be to adjust the dev guide. r? @petrochenkov
… r=petrochenkov Move remaining `NodeId` APIs from `Definitions` to `Resolver` Implements rust-lang#73291 (comment) TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed. After this, the only remaining work for rust-lang#50928 should be to adjust the dev guide. r? @petrochenkov
HirId
s were introduced in bc259ee (March 2017) as a replacement forast::NodeId
s after HIR lowering; this is said to be good for incremental compilation. The commentary for pull request #43740 (August 2017) says:The HIR chapter of the rustc development guide similarly says "while [
NodeId
s] are still in common use, they are being slowly phased out" (emphasis in original).However, a drawback of the "gradually migrate over to the new way of doing things in the course of addressing other issues" strategy is that it's all too easy for the codebase to remain in a transitional state indefinitely. Thus, perhaps we should have this dedicated issue to track progress towards not using
NodeId
s after HIR lowering.The text was updated successfully, but these errors were encountered: