Move the definition of DefId to librustc
#27856
Conversation
|
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
nikomatsakis
force-pushed
the
move-def-id-to-rustc
branch
from
e7fc786 to
0b21080
Compare
| } | ||
| } | ||
|
|
||
| impl DefId { |
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 |
| Some(ast_map::NodeTraitItem(..)) | | ||
| Some(ast_map::NodeVariant(..)) | | ||
| Some(ast_map::NodeStructCtor(..)) => { | ||
| return write!(f, " => {}", tcx.item_path_str(*self)); |
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 |
nikomatsakis
force-pushed
the
move-def-id-to-rustc
branch
3 times, most recently
from
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. |
nikomatsakis
force-pushed
the
move-def-id-to-rustc
branch
from
3521bf3 to
c71466f
Compare
nikomatsakis
force-pushed
the
move-def-id-to-rustc
branch
from
c71466f to
d735c65
Compare
|
☔ The latest upstream changes (presumably #27860) made this pull request unmergeable. Please resolve the merge conflicts. |
nikomatsakis
force-pushed
the
move-def-id-to-rustc
branch
from
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: