Uh oh!
There was an error while loading. Please reload this page.
Introduce HirId, a replacement for ast::NodeId after lowering to HIR - #40518
Merged
Conversation
michaelwoeristerforce-pushed
the
hir-id
branch
2 times, most recently
from
March 15, 2017 14:14
14150c7 to
2efd813Comparemichaelwoerister
commented
Mar 15, 2017
MemberAuthor
Alright, this passes |
michaelwoerister
commented
Mar 16, 2017
MemberAuthor
Just pushed another commit that prepares some things for using HirIds as keys in the HIR map. |
eddyb
reviewed
Mar 17, 2017
| // 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 |
Contributor
There was a problem hiding this comment.
Hahahaha I think I remember when this changed due to syntactical elision.
eddyb
commented
Mar 17, 2017
Contributor
@bors r+ |
bors
commented
Mar 17, 2017
Collaborator
📌 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
bors
commented
Mar 21, 2017
Collaborator
🔒 Merge conflict |
bors
commented
Mar 21, 2017
Collaborator
☔ 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.
This way we can have all item-likes occupy a dense range of DefIndexes, which is good for making fast, array-based dictionaries.
michaelwoerister
commented
Mar 22, 2017
MemberAuthor
@bors r=eddyb Rebased. |
bors
commented
Mar 22, 2017
Collaborator
📌 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
This file contains hidden or 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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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