-
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
Use hir::ItemLocalId instead of ast::NodeId in rustc::middle::region::CodeExtent. #44171
Conversation
dfd14c4
to
46ba34a
Compare
Crater report shows no regressions, so I'm pretty confident this works. |
☔ The latest upstream changes (presumably #43968) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
OK, I can't claim to have read these in depth, but everything looked straightforward to me. Basically what I would expect.
|
||
/// If there are any `yield` nested within a scope, this map | ||
/// stores the `Span` of the first one. | ||
yield_in_scope: FxHashMap<CodeExtent, Span>, |
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 did you have to add this?
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.
er, never mind, I found the answer later.
@bors r+ |
📌 Commit 46ba34a has been approved by |
@bors r=nikomatsakis |
📌 Commit ae82c78 has been approved by |
☔ The latest upstream changes (presumably #43932) made this pull request unmergeable. Please resolve the merge conflicts. |
@bors r=nikomatsakis |
📌 Commit 7c18f29 has been approved by |
⌛ Testing commit 7c18f29d1aece4414ada3c74e74f6ee5343e3f84 with merge a5d023839e716258e1e4e7caf193e7799f57420a... |
💔 Test failed - status-appveyor |
Hmm, the failure looks spurious to me:
|
@bors retry
|
⌛ Testing commit 7c18f29d1aece4414ada3c74e74f6ee5343e3f84 with merge 8547ab847c9d633d86b8bd1d647f42bb226e90ed... |
💔 Test failed - status-travis |
@bors retry
|
⌛ Testing commit 7c18f29d1aece4414ada3c74e74f6ee5343e3f84 with merge 3a544be3fba295f7b27e64831430c44da770ead5... |
💔 Test failed - status-travis |
Is nothing landing lately? |
@bors retry #40474 (still
|
@bors r=nikomatsakis |
📌 Commit e4996ec has been approved by |
Use hir::ItemLocalId instead of ast::NodeId in rustc::middle::region::CodeExtent. This is an alternative to @michaelwoerister's #43887, changing `CodeExtent` instead of `ReScope`. The benefit here is that the same `Region`s are used same-crate and cross-crate, while preserving the incremental recompilation properties of the stable `hir::ItemLocalId`. Only places which needed to get back to the `ast::NodeId` from `CodeExtent` was its `span` method, used in error reporting - passing the `&RegionMaps` down allowed using `hir_to_node_id`. `rustc::cfg` and `dataflow` also had to be converted to `hir::ItemLocalId` because of their interactions with `CodeExtent`, especially in `borrowck`, and from that we have 3 more `hir_to_node_id` calls: `cfg::graphviz` node labels, `borrowck` move reporting, and the `unconditional_recursion` lint. Out of all of those, *only* the lint actually makes a decision (on whether code will compile) based on the result of the conversion, the others only use it to know how to print information to the user. So I think we're safe to say that the bulk of the code working with a `CodeExtent` is fine with local IDs. r? @nikomatsakis
☀️ Test successful - status-appveyor, status-travis |
Nice, thanks a lot @eddyb! |
Store fewer NodeIds in crate metadata. The first commit just replaces `NodeId` with `DefId` in `resolve_lifetime::Region`, so we don't run into problems when stable-hashing `TypeParameterDef` values from other crates. ~~The second commit is more interesting. It adds the `ReScopeAnon` variant to `ty::RegionKind`, which is semantically equivalent to `ReScope`. The only difference is that it does not contain a `CodeExtent` field. All `ReScope` occurrences are then replaced with `ReScopeAnon` upon metadata export. This way we don't end up with `NodeIds` from other crates in various things imported from metadata. `ReScopeAnon` can still be tested for equality.~~ This is fixed in a better way by @eddyb in #44171. r? @eddyb cc @rust-lang/compiler
This is an alternative to @michaelwoerister's #43887, changing
CodeExtent
instead ofReScope
.The benefit here is that the same
Region
s are used same-crate and cross-crate, while preserving the incremental recompilation properties of the stablehir::ItemLocalId
.Only places which needed to get back to the
ast::NodeId
fromCodeExtent
was itsspan
method, used in error reporting - passing the&RegionMaps
down allowed usinghir_to_node_id
.rustc::cfg
anddataflow
also had to be converted tohir::ItemLocalId
because of their interactions withCodeExtent
, especially inborrowck
, and from that we have 3 morehir_to_node_id
calls:cfg::graphviz
node labels,borrowck
move reporting, and theunconditional_recursion
lint.Out of all of those, only the lint actually makes a decision (on whether code will compile) based on the result of the conversion, the others only use it to know how to print information to the user.
So I think we're safe to say that the bulk of the code working with a
CodeExtent
is fine with local IDs.r? @nikomatsakis