-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Track more crate metadata #42598
Track more crate metadata #42598
Conversation
fa4c3bc
to
c8c90e3
Compare
☔ The latest upstream changes (presumably #42537) made this pull request unmergeable. Please resolve the merge conflicts. |
src/librustc/ty/maps.rs
Outdated
[] is_allocator: MetaDataByCrateNum(CrateNum) -> bool, | ||
[] is_panic_runtime: MetaDataByCrateNum(CrateNum) -> bool, | ||
|
||
[] extern_crate: MetaDataByCrateNum(CrateNum) -> Rc<Option<ExternCrate>>, |
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.
I think I'd rather all of these use DefId
with DEF_INDEX_CRATE
. What do you think, @nikomatsakis?
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.
I would think that CrateNum
would be preferred -- it seems clearer -- why do you think DefId
, @eddyb?
One note: under the new dep-node system, a DepNode(CrateNum)
is perfectly fine, and we should be able to handle it well (in the past, the "retracing" only worked for DefId
, so we avoided using CrateNum
in a DepNode
.)
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.
Some of these are literally the same as querying the attributes of the crate root of some extern crate (they should also probably be replaced with an actual attribute query but that's another question), so to me they make more sense as a property of that DefId
instead of that of the CrateNum
(the latter would make sense for e.g. all impl
items in a crate).
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 don't see it that way -- that is, I see putting the attributes on the crate root as a way of specifying properties that apply to the crate as a whole, but I have no strong opinion here. I'd be happy either way.
@@ -117,7 +117,7 @@ pub fn is_const_fn(tcx: TyCtxt, def_id: DefId) -> bool { | |||
false | |||
} | |||
} else { | |||
tcx.sess.cstore.is_const_fn(def_id) | |||
tcx.is_const_fn(def_id) |
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.
You could replace all of these "check locally or externally if a fn
is const
" helpers if you had is_const_fn
also for the local crate.
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.
👍, that seems like it would be nicer
src/librustc/dep_graph/dep_node.rs
Outdated
@@ -93,6 +94,7 @@ pub enum DepNode<D: Clone + Debug> { | |||
ItemSignature(D), | |||
ItemVarianceConstraints(D), | |||
ItemVariances(D), | |||
IsConstFn(D), |
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.
note that this whole mechanism recently changed, so you'll have to rebase it-- in the new version, you would just write DefId
here
fmts.insert(ty, linkage); | ||
} | ||
sess.abort_if_errors(); | ||
} | ||
|
||
fn calculate_type(sess: &session::Session, | ||
fn calculate_type<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, | ||
ty: config::CrateType) -> DependencyList { |
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.
Nit: indentation
fmts.insert(ty, linkage); | ||
} | ||
sess.abort_if_errors(); | ||
} | ||
|
||
fn calculate_type(sess: &session::Session, | ||
fn calculate_type<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, |
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.
Random aside: I feel like a GlobalTyCtxt<'a, 'tcx>
alias might be nice.
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.
At that point, the Ty
part is maybe a bit unnecessary and we should move towards a generalized idea of a "global context" (aka god object).
This generally looks good to me. Needs a rebase, and we have to decide on |
39ae2a3
to
c53193e
Compare
c53193e
to
4835698
Compare
src/librustc_metadata/cstore_impl.rs
Outdated
|
||
$(fn $cnum_fn_name<'a, $lt:$lt>($tcx: TyCtxt<'a, $lt, $lt>, $cnum: CrateNum) | ||
-> <ty::queries::$cnum_fn_name<$lt> as | ||
DepTrackingMapConfig>::Value { |
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.
I didn't see a way to explicitly generate a dep_node
from a CrateNum
under the new system, so this section is missing a call to $tcx.dep_graph.read(dep_node)
.
@nikomatsakis @eddyb Did you decide whether or not this should be a DefId
instead?
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.
It would just be easier to use DefId
IMO...
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.
I think we settled on DefId
.
@michaelwoerister can probably tell you how to make a dep-node from a CrateNum
. I'll try to figure it out later but don't have time for digging right now.
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.
@michaelwoerister can probably tell you how to make a dep-node from a CrateNum. I'll try to figure it out later but don't have time for digging right now.
If we're just going to use DefId
s for all of them, there's no need. Thanks, though!
Currently triggering this assertion after switching to |
Oh? Let me check out the commit... |
oh, I See what's happening. Yeah, that code assumes that there are some dep-nodes classified as base inputs, and that these have no predecessors in the depdendency graph. But when you use |
I think last time we either opted for more specific query |
Gotcha. I'll split them apart into separate |
@bors r+ |
📌 Commit e6dd869 has been approved by |
Track more crate metadata Part of #41417 r? @nikomatsakis
☀️ Test successful - status-appveyor, status-travis |
extern_crate => { Rc::new(cdata.extern_crate.get()) } | ||
} | ||
|
||
pub fn provide_local<'tcx>(providers: &mut Providers<'tcx>) { |
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.
Ahhh I missed this. No, this has no business being here, it should be in rustc
or rustc_typeck
.
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.
Ah sorry-- I was just moving all of the former crate metadata functions into this spot.
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.
Well this one is for the local crate, which rustc_metadata
is not about. Only noticed it because I wanted to change it (didn't have to in the end) and I couldn't find it 😆.
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.
which
rustc_metadata
is not about
Why did it used to be a method on CStore
?
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.
That's only the cross-crate half of it.
Part of #41417
r? @nikomatsakis