Skip to content

query for def_span - #41593

Merged
bors merged 7 commits into
rust-lang:masterfrom
hackeryarn:def_span
Apr 30, 2017
Merged

query for def_span#41593
bors merged 7 commits into
rust-lang:masterfrom
hackeryarn:def_span

Conversation

@hackeryarn

Copy link
Copy Markdown
Contributor

Resolves fn def_span(&self, sess: &Session, def: DefId) -> Span; of #41417.

I had to change the query name to def_sess_span since ty::TyCtxt already has a method def_span implemented.

This also will probably have merge conflicts with #41534 but I will resolves those once it's merged and wanted to start a code review on this one now.

r? @eddyb

@rust-highfive

Copy link
Copy Markdown
Contributor

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@eddyb

Copy link
Copy Markdown
Contributor
  1. The session is not the interesting part of tcx.sess.cstore, cstore is ("crate store").
  2. You can replace the tcx method with this one, just need a local provider too.

@bors

bors commented Apr 28, 2017

Copy link
Copy Markdown
Collaborator

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

@shepmastershepmaster added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Apr 28, 2017
@hackeryarn

Copy link
Copy Markdown
ContributorAuthor

@eddyb, I am not sure why this failed. I replaced the function as you suggested and included a provider. I am guessing it has to do with how I'm handling the tcx.sess.cstore span in the provider, but I could not think of a different way of getting a Span if it's not available as a local node.

Comment threadsrc/librustc/ty/maps.rs Outdated

pub describe_def: meta_data_node(DefId) -> Option<Def>
pub describe_def: meta_data_node(DefId) -> Option<Def>,
pub def_span: meta_data_node(DefId) -> Span

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, what is meta_data_node? First off, it doesn't need a function, it could just be MetaData.
Secondly, if you have a local crate implementation, you kind of need a node that's not MetaData.
But if @nikomatsakis doesn't think this impacts incremental this can be left as-is for now.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was actually added as part of my last PR. I will remove it form both instances and replace it with just MetaData.

Comment threadsrc/librustc/ty/mod.rs Outdated
match tcx.hir.span_if_local(def_id) {
Some(span) => span,
None => {
let node_id = tcx.sess.cstore.item_body(tcx, def_id).id().node_id;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm surprised you found item_body - that's really only meant to be used by const evaluation.
You should really be panicking if the DefId isn't local (i.e. you can .unwrap() the result of span_if_local instead of handling the None case) - because the line you added in src/librustc_metadata/cstore_impl.rs is what actually handles that case.

@eddyb

Copy link
Copy Markdown
Contributor

Aaaaah, the stack overflow is because by default the span used in the "query cycle" printout comes from tcx.def_span(def_id) - you have to somehow override that for def_span.
Not sure this is even easy atm, since we do some things through Key or Value, not something implemented on the query itself - you can probably use match on the Query enum created from the query type and see if it's specifically the def_span variant.

@hackeryarn

Copy link
Copy Markdown
ContributorAuthor

I've updated your suggestions, but I will need to spend some more time on the stack overflow error.

@bors

bors commented Apr 28, 2017

Copy link
Copy Markdown
Collaborator

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

@hackeryarn

Copy link
Copy Markdown
ContributorAuthor

@eddyb I believe this addresses all your requests and the stack overflow issue.

// FIXME(eddyb) Get more valid Span's on queries.
if span == DUMMY_SP {
span = key.default_span(tcx);
if span == DUMMY_SP && stringify!($name) != "def_span" {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is not too bad of a workaround - could you leave a comment above as to why this is done?

Comment threadsrc/librustc/ty/maps.rs Outdated

[] describe_def: meta_data_node(DefId) -> Option<Def>

[] describe_def: MetaData(DefId) -> Option<Def>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary extra empty line.

@eddyb

Copy link
Copy Markdown
Contributor

You're getting failures because you're using MetaData which is special - may I suggest adding a DescribeDef and a DefSpan variants to DepNode?

@hackeryarn

Copy link
Copy Markdown
ContributorAuthor

@eddyb this should resolve everything. Thanks for the DepNode suggestion I like the explicitness of that approach 😄

Comment threadsrc/librustc/dep_graph/dep_node.rs Outdated
// not a hotspot.
ProjectionCache { def_ids: Vec<D> },

// Depnodes for MetaData

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heh, you can leave the comment off - the reason we need these is becauseMetaData can't be used, as it's reserved for cross-crate queries, e.g. ItemSignature(def_id) will eventually depend on either Hir(def_id) iff def_id.is_local() or MetaData(def_id) otherwise.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah that makes sense the title of the issue was deceiving. I assumed all of these were just about crate metadata.

Comment threadsrc/librustc/ty/maps.rs Outdated
}

fn def_span(def_id: DefId) -> DepNode<DefId> {
DepNode::DefSpan(def_id)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These aren't needed, because they're just a DepNode variant - the explicit functions are in cases where you can't just use DepNode::VariantName(def_id).

@eddyb

Copy link
Copy Markdown
Contributor

@bors r+

@bors

bors commented Apr 29, 2017

Copy link
Copy Markdown
Collaborator

📌 Commit d3b7af0 has been approved by eddyb

@frewsxcvfrewsxcv mentioned this pull request Apr 29, 2017
@bors

bors commented Apr 30, 2017

Copy link
Copy Markdown
Collaborator

⌛ Testing commit d3b7af0 with merge ba5b911...

bors added a commit that referenced this pull request Apr 30, 2017
query for def_span
Resolves `fn def_span(&self, sess: &Session, def: DefId) -> Span;` of #41417.
I had to change the query name to `def_sess_span` since `ty::TyCtxt` already has a method `def_span` implemented.
This also will probably have merge conflicts with #41534 but I will resolves those once it's merged and wanted to start a code review on this one now.
r? @eddyb
@bors

bors commented Apr 30, 2017

Copy link
Copy Markdown
Collaborator

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing ba5b911 to master...

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-authorStatus: 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.

5 participants

@hackeryarn@rust-highfive@eddyb@bors@shepmaster