-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Refactor ensure
and try_get_with
#45312
Conversation
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.
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
Thanks for the PR, @theotherjimmy! I like the code deduplication. However could you:
|
The argument for privacy makes sense and I'll move it. The reason that I put it where I did, is that it did not need to be duplicated for each query type.
Ah, the hardest problem in computer science: naming. Another commit is on the way with the move and rename. Don't hold your breath, it may be a few hours. |
You could try and see if you can make this a free-standing function in |
Thanks for the tip. I'll give that a try. |
@michaelwoerister I pushed up a commit that should address your review comments. I also moved the implementation of |
77e7c14
to
b335efc
Compare
Please excuse the rebase. I forgot to delete the old implementation of |
This should limit the availability of `try_mark_green_and_read` making it harder to abuse.
b335efc
to
229bee3
Compare
Thanks @theotherjimmy! I think you've found the right place to put the function. @bors r+ |
📌 Commit 229bee3 has been approved by |
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
💔 Test failed - status-travis |
@bors retry
|
ensure
and try_get_with
into read_node_index
ensure
and try_get_with
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
☀️ Test successful - status-appveyor, status-travis |
There was a bit of code shared between
try_get_with
andensure
, after Iadded
ensure
. I refactored that shared code into a query-agnostic methodcalled
read_node_index
.The new method
read_node_index
will attempt to find the nodeindex (
DepNodeIndex
) of a query. Whenread_node_index
finds theDepNodeIndex
, it marks the current query as a reader of the node it'srequesting the index of.
This is used by
try_get_with
andensure
as it elides the unimportant (tothem) 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
andensure
, they just need to know if they can lookup the results or have toreevaluate.
@nikomatsakis this is the refactor we discussed in the comment thread of #45228