Move the definition of DefId to librustc#27856
Conversation
|
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
e7fc786 to
0b21080
Compare
src/librustc/middle/def_id.rs
Outdated
There was a problem hiding this comment.
Could you have an as_local(&self) -> Option<NodeId> method instead of using .krate == LOCAL_CRATE everywhere?
There was a problem hiding this comment.
Could you have an as_local(&self) -> Option method instead of using .krate == LOCAL_CRATE everywhere?
We have is_local() as well, I could convert some code to use that.
But you just reminded me that I meant to purge the DEF_ID_DEBUG thing...
There was a problem hiding this comment.
(But as_local would be nice too to be more type-safe)
There was a problem hiding this comment.
Hmm, I guess DEF_ID_DEBUG may still have value, I'm not sure if the tcx is ALWAYS available when DefIds are being debugged, and there doesn't seem to be a method for "conditionally" reading the current tcx.
There was a problem hiding this comment.
I was going to mention it but I see you've already thought about doing it.
The only method that needs to be exposed is is_set.
|
@eddyb what are your thoughts about |
|
LGTM after the |
|
@arielb1 I investigated |
|
r? @eddyb |
src/librustc/middle/def_id.rs
Outdated
There was a problem hiding this comment.
I'm not sure there's even a point to restricting this to only certain nodes anymore, if there ever was.
There was a problem hiding this comment.
I'm not sure there's even a point to restricting this to only certain nodes anymore, if there ever was.
perhaps not; looking over the code it seems like it will always gin up some kind of path, even if it's an empty or useless one.
|
r=me after optionally removing the node kind restriction (does something break if you do?) and maybe even printing |
755fbf7 to
3521bf3
Compare
|
@bors r=eddyb |
|
📌 Commit 3521bf3 has been approved by |
|
⌛ Testing commit 3521bf3 with merge 7d400d6... |
|
💔 Test failed - auto-mac-32-opt |
|
☔ The latest upstream changes (presumably #27833) made this pull request unmergeable. Please resolve the merge conflicts. |
3521bf3 to
c71466f
Compare
c71466f to
d735c65
Compare
|
☔ The latest upstream changes (presumably #27860) made this pull request unmergeable. Please resolve the merge conflicts. |
d735c65 to
1994875
Compare
|
@bors r=eddyb |
|
📌 Commit 1994875 has been approved by |
It doesn't really make sense for DefId to be in libsyntax -- it is concerned with a single crate only. It is the compiler that understands the idea of many crates. (At some point, there might be a useful intermediate point here.) This is a refactoring in support of incr. compilation, which will be adjusting the notion of a DefId to make it more durable across compilations.
This will probably be a [breaking-change] for every plugin ever. You need to adjust things as follows:
use rustc::middle::def_id::{DefId, LOCAL_CRATE}; // two most common definitions
ast_util::is_local(def_id) => def_id.is_local()
ast_util::local_def(node_id) => DefId::local(node_id)
It doesn't really make sense for DefId to be in libsyntax -- it is concerned with a single crate only. It is the compiler that understands the idea of many crates. (At some point, there might be a useful intermediate point here.) This is a refactoring in support of incr. compilation, which will be adjusting the notion of a DefId to make it more durable across compilations.
This will probably be a [breaking-change] for every plugin ever. You need to adjust things as follows: