-
Notifications
You must be signed in to change notification settings - Fork 13.4k
improve search graph docs, reset encountered_overflow
between reruns
#142617
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
base: master
Are you sure you want to change the base?
Conversation
// optimization. However, given that the proof tree will likely | ||
// look similar to the previous iterations when reevaluating, it's | ||
// better for caching if the reevaluation also starts out with `false` | ||
encountered_overflow: 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've reworked this to use EvaluationResult
as I've accidentally dropped heads
from previous iterations while working on this change and it took me a bit to actually figure out what's going on. This now makes it clear that we need to track everything correctly.
@@ -26,6 +26,10 @@ pub(super) struct StackEntry<X: Cx> { | |||
/// The available depth of a given goal, immutable. | |||
pub available_depth: AvailableDepth, | |||
|
|||
/// Starts out as `None` and gets set when rerunning this | |||
/// goal in case we encounter a cycle. | |||
pub provisional_result: Option<X::Result>, |
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.
moving this field as this type is now all the immutable fields and then the mutable ones
encountered_overflow
between rerunsencountered_overflow
between reruns
This comment was marked as outdated.
This comment was marked as outdated.
also return `EvaluationResult` instead of the final `StackEntry` to make sure we correctly track information between reruns.
I think this shouldn't really matter for now. It will be more relevant for my current rework as we otherwise cannot partially reevaluate the root goal in case there has been overflow during the prervious iteration.
r? @BoxyUwU