-
Notifications
You must be signed in to change notification settings - Fork 13.3k
incr.comp.: Introduce ensure
and ensure
typeck_tables_of
#45228
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
Conversation
`$query::ensure()` guarantees that one of two things is true after it returns: - The query has all green inputs. - The query has been executed. and counts as a read from the source query
This should make TypeckTables lazier.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (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. |
if !tcx.dep_graph.is_fully_enabled() { | ||
let _ = tcx.$name(key); | ||
return; | ||
} |
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.
@nikomatsakis Open question: Should the preceding 4 lines be in try_mark_green
?
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.
For reference, try_mark_green
will unwrap
a None
here if tcx.dep_graph.is_fully_enabled()
would return False.
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'd rather keep the explicit panic
in try_mark_green
, I think.
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'll leave the code here as it is then.
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 also expected those lines to be in try_mark_green
, but I trust @michaelwoerister's intuitions here. =) That said, I think we could consider trying to extract some of the common code between this function and try_get_with
. I had thought it might make sense to extract a helper function that returns Some(dep_node_index)
if either: the node color is green or can be made green, and None
otherwise. This function here could invoke tcx.$name(key)
if None
is returned, and try_get_with
can do whatever it does 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.
I like it! I'll implement that refactor as a follow on PR, unless this round of testing does not go well and I have to fix something.
src/librustc/ty/maps/plumbing.rs
Outdated
use dep_graph::DepNodeColor; | ||
match tcx.dep_graph.node_color(&dep_node) { | ||
Some(DepNodeColor::Green(dep_node_index)) => { | ||
profq_msg!(tcx, ProfileQueriesMsg::CacheHit); |
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.
We shouldn't do any profq_msg!
calls in this method for now. We'll have to talk to @matthewhammer at some point about how to properly integrate the new tracking system with the query profiler.
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'll pull them out. Thanks.
src/librustc/ty/maps/plumbing.rs
Outdated
tcx.dep_graph.read_index(dep_node_index); | ||
} | ||
Some(DepNodeColor::Red) => { | ||
let _ = tcx.$name(key); |
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.
Could you add a comment here saying something like:
The DepNode being DepNodeColor::Red means that this query has been already executed before. We are still calling the proper again in order to issue the appropriate
dep_graph.read()
call. The performance cost this introduces should be negligible because we'll immediately hit the in-memory cache.
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.
Yes. Just a moment.
@michaelwoerister I think I corrected everything you pointed out in your review comments. Thanks for the review! |
Thanks @theotherjimmy! @bors r+ |
📌 Commit d0cb4d0 has been approved by |
incr.comp.: Introduce `ensure` and `ensure` typeck_tables_of Resolves #45210 In this Pull Request we introduce the `ensure` query/function. `ensure` has the semantics and type of the function `Q1` below: ```rust fn Q1::ensure(K){ Q(K); } ``` Further, `ensure` avoids the need to load the result from disk (or execute the provider, if we are not storing the results of Q to disk). @nikomatsakis
☀️ Test successful - status-appveyor, status-travis |
🎉 |
Refactor `ensure` and `try_get_with` into `read_node_index` There was a bit of code shared between `try_get_with` and `ensure`, after I added `ensure`. I refactored that shared code into a query-agnostic method called `read_node_index`. The new method `read_node_index` will attempt to find the node index (`DepNodeIndex`) of a query. When `read_node_index` finds the `DepNodeIndex`, it marks the current query as a reader of the node it's requesting the index of. This is used by `try_get_with` and `ensure` as it elides the unimportant (to them) details of if the query is invalidated by previous changed computation (Red) or new and if they had to mark the query green. For both `try_get_with` and `ensure`, they just need to know if they can lookup the results or have to reevaluate. @nikomatsakis this is the [refactor we discussed](#45228 (comment)) in the comment thread of #45228
Refactor `ensure` and `try_get_with` There was a bit of code shared between `try_get_with` and `ensure`, after I added `ensure`. I refactored that shared code into a query-agnostic method called `read_node_index`. The new method `read_node_index` will attempt to find the node index (`DepNodeIndex`) of a query. When `read_node_index` finds the `DepNodeIndex`, it marks the current query as a reader of the node it's requesting the index of. This is used by `try_get_with` and `ensure` as it elides the unimportant (to them) details of if the query is invalidated by previous changed computation (Red) or new and if they had to mark the query green. For both `try_get_with` and `ensure`, they just need to know if they can lookup the results or have to reevaluate. @nikomatsakis this is the [refactor we discussed](#45228 (comment)) in the comment thread of #45228
Resolves #45210
In this Pull Request we introduce the
ensure
query/function.ensure
has thesemantics and type of the function
Q1
below:Further,
ensure
avoids the need to load the result from disk (or execute theprovider, if we are not storing the results of Q to disk).
@nikomatsakis