-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Properly stall coroutine witnesses in new solver #138845
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
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor changes to |
/// entered before passing `value` to the function. This is currently needed for | ||
/// `normalize_erasing_regions`, which skips binders as it walks through a type. | ||
/// | ||
/// TODO: doc |
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 need to explain that this doesn't return all ambiguous preds, just the ones that are stalled on coroutines.
This comment has been minimized.
This comment has been minimized.
Tweaks to writeback and `Obligation -> Goal` conversion Each of these commits are self-contained, but are prerequisites that I'd like to land before rust-lang#138845, which still needs some cleaning. The ""most controversial"" one is probably [Explicitly don't fold coroutine obligations in writeback](rust-lang@e7d27ba), which I prefer because I think using `fold_predicate` to control against not normalizing predicates seems... easy to mess up 🤔, and we could have *other things* that we don't want to normalize. Explicitly noting whether we want `resolve` to normalize is a lot clearer (and currently in writeback is limited to resolving stalled coroutine obligations), since we can attach it to a comment that explains *why*.
Rollup merge of rust-lang#138846 - compiler-errors:stall-prereqs, r=lcnr Tweaks to writeback and `Obligation -> Goal` conversion Each of these commits are self-contained, but are prerequisites that I'd like to land before rust-lang#138845, which still needs some cleaning. The ""most controversial"" one is probably [Explicitly don't fold coroutine obligations in writeback](rust-lang@e7d27ba), which I prefer because I think using `fold_predicate` to control against not normalizing predicates seems... easy to mess up 🤔, and we could have *other things* that we don't want to normalize. Explicitly noting whether we want `resolve` to normalize is a lot clearer (and currently in writeback is limited to resolving stalled coroutine obligations), since we can attach it to a comment that explains *why*.
☔ The latest upstream changes (presumably #138873) made this pull request unmergeable. Please resolve the merge conflicts. |
fn visit_goal(&mut self, inspect_goal: &super::inspect::InspectGoal<'_, 'tcx>) -> Self::Result { | ||
inspect_goal.goal().predicate.visit_with(self)?; | ||
|
||
if let Some(candidate) = inspect_goal.unique_applicable_candidate() { |
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.
this type visitor feels somewhat fragile and I expect unique_applicable_candidate
and the limited recursion depth to cause us to fail to stall obligations in very rare cases. otoh I don't think this is a problem though
so my understanding here is:
- for correctness it doesn't matter how many obligations we stall
- for diagnostics (and perf) we want to stall as few obligations as possible
- failing to stall causes unexpected ambiguity errors
Please add this as a comment somewhere, prolly the stalled_coroutine_obligations field of the typeck results
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.
Yep, that's my understanding. We could perhaps stall obligations if we find coroutines in the predicate or if we hit the recursion limit, but idk if we have a facility to detect when we hit the recursion limit here. Shouldn't be too hard to fix, but I'd rather leave that to when we need it.
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.
comment somewhere
Let's see how bad the perf is from making items larger. @bors try @rust-timer queue |
fb7257b
to
b6f1961
Compare
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…<try> Properly stall coroutine witnesses in new solver TODO: write description r? lcnr
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (5443aaa): comparison URL. Overall result: ❌ regressions - please read the text belowBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 1.2%, secondary -1.8%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary -1.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 777.999s -> 780.062s (0.27%) |
Let me try putting coroutines into the same list as the opaques 🤔 |
alternatively, intern |
Finished benchmarking commit (7984f3d): comparison URL. Overall result: ❌ regressions - please read the text belowBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -0.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 0.8%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 774.196s -> 774.363s (0.02%) |
7ad9c9d
to
0b7ded5
Compare
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.
nits, r=me
0b7ded5
to
f943f73
Compare
@bors r+ |
[DO NOT MERGE] bootstrap with `-Znext-solver=globally` A revival of rust-lang#124812. Current status: ~~`./x.py b --stage 2` passes 🎉~~ `try` builds succeed 🎉 🎉 🎉 ~~[top 100 most downloaded crates on crates.io compile](rust-lang#133502 (comment) [top 1000 most downloaded crates on crates.io compile](rust-lang#133502 (comment)) [first perf run](rust-lang#133502 (comment)) 👻 ### in-flight changes - rust-lang#124852, unsure whether I actually want to land this PR for now - rust-lang#139587 - https://github.com/lcnr/rust/tree/opaque-type-method-call - rust-lang#138845 - rust-lang#139762 - double the available recursion depth in the new solver ☠️ r? `@ghost`
[DO NOT MERGE] bootstrap with `-Znext-solver=globally` A revival of rust-lang#124812. Current status: ~~`./x.py b --stage 2` passes 🎉~~ `try` builds succeed 🎉 🎉 🎉 ~~[top 100 most downloaded crates on crates.io compile](rust-lang#133502 (comment) [top 1000 most downloaded crates on crates.io compile](rust-lang#133502 (comment)) [first perf run](rust-lang#133502 (comment)) 👻 ### in-flight changes - rust-lang#124852, unsure whether I actually want to land this PR for now - rust-lang#139587 - https://github.com/lcnr/rust/tree/opaque-type-method-call - rust-lang#138845 - rust-lang#139762 - double the available recursion depth in the new solver ☠️ r? `@ghost`
⌛ Testing commit f943f73 with merge fa58ce343ad498196d799a7381869e79938e952a... |
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing df35ff6 (parent) -> fa58ce3 (this PR) Test differencesShow 134 test diffs134 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard fa58ce343ad498196d799a7381869e79938e952a --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (fa58ce3): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 0.3%, secondary -1.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -0.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 775.888s -> 775.233s (-0.08%) |
lol, lmao |
slightly bigger perf impact than expected by the previous perf run 🤔 unsure what caused it and it feels minor enough for me to not look too deeply into this. |
Yeah, weirdly this is functionally equivalent to the changes I perf'd in #138845 (comment). The fact that rebasing + perf testing it again (#138845 (comment)) led to a regression, and then a worse regression after rebasing again suggests that there's some performance instability here rather than something that can be optimized. |
Fixes rust-lang/trait-system-refactor-initiative#82.
Using an infer var for the witness meant that if we constrain the infer var during writeback and then try to normalize during writeback, after the coroutine witness has been plugged into the coroutine type - which we do with the new solver - we may encounter a query cycle due to trying to fetch the coroutine witness types.
This PR changes the
AnalysisInBody
typing mode to track all coroutines being defined by the current body during typeck, and forces any auto trait andCopy
obligations that would require fetching the hidden types of these coroutines to be forced ambiguous. This also introduces a new proof tree visitor which detects which obligations should be stalled due to bottoming out in one of these ambiguous obligations, so we can re-check them after borrowck (as is done with the old solver).This PR shouldn't have functional changes, but post-mortem seems to have introduced a perf regression. Looking at the code, I don't see much of a reason why this would be the case. We don't call the new query when the old solver is active, nor should be be visiting any of this new unstalling code in the old solver.
r? lcnr