Introduce HirId, a replacement for ast::NodeId after lowering to HIR #40518
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
michaelwoerister
force-pushed
the
hir-id
branch
2 times, most recently
from
14150c7
to
2efd813
Compare
|
Alright, this passes |
|
Just pushed another commit that prepares some things for using HirIds as keys in the HIR map. |
eddyb
reviewed
Mar 17, 2017
| @@ -18,7 +18,7 @@ trait SomeTrait { } | |||
|
|
|||
| // Bounds on object types: | |||
|
|
|||
| struct Foo<'a,'b,'c> { //~ ERROR parameter `'b` is never used | |||
| struct Foo<'a,'b,'c> { //~ ERROR parameter `'c` is never used | |||
There was a problem hiding this comment.
Hahahaha I think I remember when this changed due to syntactical elision.
|
@bors r+ |
|
📌 Commit 2536302 has been approved by |
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this pull request
Mar 20, 2017
Introduce HirId, a replacement for ast::NodeId after lowering to HIR This is the first step towards implementing rust-lang#40303. This PR introduces the `HirId` type and generates a `HirId` for everything that would be assigned one (i.e. stuff in the HIR), but the HIR data types still use `NodeId` for now. Changing that is a big refactoring that I want to do in a separate PR. A `HirId` uniquely identifies a node in the HIR of the current crate. It is composed of the `owner`, which is the `DefIndex` of the directly enclosing `hir::Item`, `hir::TraitItem`, or `hir::ImplItem` (i.e. the closest "item-like"), and the `local_id` which is unique within the given owner. This PR is also running a number of consistency checks for the generated `HirId`s: - Does `NodeId` in the HIR have a corresponding `HirId`? - Is the `owner` part of each `HirId` consistent with its position in the HIR? - Do the numerical values of the `local_id` part all lie within a dense range of integers? cc @rust-lang/compiler r? @eddyb or @nikomatsakis
|
🔒 Merge conflict |
|
☔ The latest upstream changes (presumably #40693) made this pull request unmergeable. Please resolve the merge conflicts. |
HirId has a more stable representation than NodeId, meaning that modifications to one item don't influence (part of) the IDs within other items. The other part is a DefIndex for which there already is a way of stable hashing and persistence. This commit introduces the HirId type and generates a HirId for every NodeId during HIR lowering, but the resulting values are not yet used anywhere, except in consistency checks.
michaelwoerister
force-pushed
the
hir-id
branch
from
2536302
to
f7170fc
Compare
This way we can have all item-likes occupy a dense range of DefIndexes, which is good for making fast, array-based dictionaries.
michaelwoerister
force-pushed
the
hir-id
branch
from
f7170fc
to
090767b
Compare
|
@bors r=eddyb Rebased. |
|
📌 Commit 090767b has been approved by |
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this pull request
Mar 23, 2017
Introduce HirId, a replacement for ast::NodeId after lowering to HIR This is the first step towards implementing rust-lang#40303. This PR introduces the `HirId` type and generates a `HirId` for everything that would be assigned one (i.e. stuff in the HIR), but the HIR data types still use `NodeId` for now. Changing that is a big refactoring that I want to do in a separate PR. A `HirId` uniquely identifies a node in the HIR of the current crate. It is composed of the `owner`, which is the `DefIndex` of the directly enclosing `hir::Item`, `hir::TraitItem`, or `hir::ImplItem` (i.e. the closest "item-like"), and the `local_id` which is unique within the given owner. This PR is also running a number of consistency checks for the generated `HirId`s: - Does `NodeId` in the HIR have a corresponding `HirId`? - Is the `owner` part of each `HirId` consistent with its position in the HIR? - Do the numerical values of the `local_id` part all lie within a dense range of integers? cc @rust-lang/compiler r? @eddyb or @nikomatsakis
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the first step towards implementing #40303. This PR introduces the
HirIdtype and generates aHirIdfor everything that would be assigned one (i.e. stuff in the HIR), but the HIR data types still useNodeIdfor now. Changing that is a big refactoring that I want to do in a separate PR.A
HirIduniquely identifies a node in the HIR of the current crate. It is composed of theowner, which is theDefIndexof the directly enclosinghir::Item,hir::TraitItem, orhir::ImplItem(i.e. the closest "item-like"), and thelocal_idwhich is unique within the given owner.This PR is also running a number of consistency checks for the generated
HirIds:NodeIdin the HIR have a correspondingHirId?ownerpart of eachHirIdconsistent with its position in the HIR?local_idpart all lie within a dense range of integers?cc @rust-lang/compiler
r? @eddyb or @nikomatsakis