Skip to content
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

Merged
merged 7 commits into from
Jun 17, 2017
Merged

Track more crate metadata #42598

merged 7 commits into from
Jun 17, 2017

Conversation

cramertj
Copy link
Member

Part of #41417
r? @nikomatsakis

@carols10cents carols10cents added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 12, 2017
@bors
Copy link
Contributor

bors commented Jun 12, 2017

☔ The latest upstream changes (presumably #42537) made this pull request unmergeable. Please resolve the merge conflicts.

[] is_allocator: MetaDataByCrateNum(CrateNum) -> bool,
[] is_panic_runtime: MetaDataByCrateNum(CrateNum) -> bool,

[] extern_crate: MetaDataByCrateNum(CrateNum) -> Rc<Option<ExternCrate>>,
Copy link
Member

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?

Copy link
Contributor

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.)

Copy link
Member

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).

Copy link
Contributor

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)
Copy link
Member

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.

Copy link
Contributor

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

@@ -93,6 +94,7 @@ pub enum DepNode<D: Clone + Debug> {
ItemSignature(D),
ItemVarianceConstraints(D),
ItemVariances(D),
IsConstFn(D),
Copy link
Contributor

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 {
Copy link
Contributor

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>,
Copy link
Contributor

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.

Copy link
Member

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).

@nikomatsakis
Copy link
Contributor

This generally looks good to me. Needs a rebase, and we have to decide on CrateNum vs DefId. I don't have a strong opinion there. It'd be nice to also do the refactoring that @eddyb suggested.

@arielb1 arielb1 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 13, 2017
@cramertj cramertj force-pushed the track-more-metadata branch 2 times, most recently from 39ae2a3 to c53193e Compare June 14, 2017 06:14

$(fn $cnum_fn_name<'a, $lt:$lt>($tcx: TyCtxt<'a, $lt, $lt>, $cnum: CrateNum)
-> <ty::queries::$cnum_fn_name<$lt> as
DepTrackingMapConfig>::Value {
Copy link
Member Author

@cramertj cramertj Jun 14, 2017

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?

Copy link
Member

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...

Copy link
Contributor

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.

Copy link
Member Author

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 DefIds for all of them, there's no need. Thanks, though!

@cramertj
Copy link
Member Author

Currently triggering this assertion after switching to DefId.

@nikomatsakis
Copy link
Contributor

Oh? Let me check out the commit...

@nikomatsakis
Copy link
Contributor

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 MetaData(DefId) as the query dep-node, it will have inputs. You should probably make some other dep node like MetaDataQuery(DefId).

@eddyb
Copy link
Member

eddyb commented Jun 15, 2017

I think last time we either opted for more specific query DepNodes or added some catchall.
Definitely do not use MetaData as a query DepNode (I don't think I've seen the current state).

@cramertj
Copy link
Member Author

Gotcha. I'll split them apart into separate DepNodes.

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Jun 16, 2017

📌 Commit e6dd869 has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Jun 16, 2017

⌛ Testing commit e6dd869 with merge 3cb8034...

bors added a commit that referenced this pull request Jun 16, 2017
@bors
Copy link
Contributor

bors commented Jun 17, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 3cb8034 to master...

@bors bors merged commit e6dd869 into rust-lang:master Jun 17, 2017
@cramertj cramertj deleted the track-more-metadata branch June 17, 2017 00:07
extern_crate => { Rc::new(cdata.extern_crate.get()) }
}

pub fn provide_local<'tcx>(providers: &mut Providers<'tcx>) {
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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 😆.

Copy link
Member Author

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?

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants