Skip to content

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

Merged
merged 6 commits into from
Apr 24, 2025

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Mar 22, 2025

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 and Copy 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

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Mar 22, 2025
@rustbot
Copy link
Collaborator

rustbot commented Mar 22, 2025

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

changes to inspect_obligations.rs

cc @compiler-errors, @lcnr

/// 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
Copy link
Member Author

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.

@rust-log-analyzer

This comment has been minimized.

jhpratt added a commit to jhpratt/rust that referenced this pull request Mar 24, 2025
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*.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 24, 2025
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*.
@bors
Copy link
Collaborator

bors commented Mar 24, 2025

☔ 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() {
Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

comment somewhere

@compiler-errors
Copy link
Member Author

Let's see how bad the perf is from making items larger.

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Mar 25, 2025
@compiler-errors
Copy link
Member Author

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 25, 2025
…<try>

Properly stall coroutine witnesses in new solver

TODO: write description

r? lcnr
@bors
Copy link
Collaborator

bors commented Mar 25, 2025

⌛ Trying commit b6f1961 with merge 5443aaa...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Mar 25, 2025

☀️ Try build successful - checks-actions
Build commit: 5443aaa (5443aaa4127ecdfcad1a50e7d7f2e4650bb52877)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (5443aaa): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking 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 @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This 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.

mean range count
Regressions ❌
(primary)
0.3% [0.1%, 0.5%] 71
Regressions ❌
(secondary)
0.3% [0.1%, 0.5%] 38
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.3% [0.1%, 0.5%] 71

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.

mean range count
Regressions ❌
(primary)
1.5% [0.5%, 3.9%] 18
Regressions ❌
(secondary)
2.5% [1.0%, 3.9%] 3
Improvements ✅
(primary)
-1.6% [-2.5%, -0.7%] 2
Improvements ✅
(secondary)
-3.7% [-6.8%, -0.9%] 7
All ❌✅ (primary) 1.2% [-2.5%, 3.9%] 20

Cycles

Results (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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
2.0% [2.0%, 2.0%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.7% [-4.5%, -1.0%] 2
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 777.999s -> 780.062s (0.27%)
Artifact size: 365.81 MiB -> 365.88 MiB (0.02%)

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Mar 25, 2025
@compiler-errors
Copy link
Member Author

Let me try putting coroutines into the same list as the opaques 🤔

@lcnr
Copy link
Contributor

lcnr commented Mar 25, 2025

alternatively, intern TypingEnv itself. We should only very rarely access its value and it's already 2 ptrs wide

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (7984f3d): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking 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 @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This 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.

mean range count
Regressions ❌
(primary)
0.1% [0.1%, 0.1%] 3
Regressions ❌
(secondary)
0.2% [0.1%, 0.2%] 10
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.1% [0.1%, 0.1%] 3

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.

mean range count
Regressions ❌
(primary)
0.8% [0.8%, 0.8%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.7% [-0.9%, -0.4%] 2
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.2% [-0.9%, 0.8%] 3

Cycles

Results (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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.8% [0.8%, 0.8%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 774.196s -> 774.363s (0.02%)
Artifact size: 365.08 MiB -> 365.20 MiB (0.03%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Apr 23, 2025
@compiler-errors compiler-errors marked this pull request as ready for review April 23, 2025 14:21
Copy link
Contributor

@lcnr lcnr left a comment

Choose a reason for hiding this comment

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

nits, r=me

@lcnr
Copy link
Contributor

lcnr commented Apr 23, 2025

@bors r+

@bors
Copy link
Collaborator

bors commented Apr 23, 2025

📌 Commit f943f73 has been approved by lcnr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 23, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 23, 2025
[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`
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 23, 2025
[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`
@bors
Copy link
Collaborator

bors commented Apr 23, 2025

⌛ Testing commit f943f73 with merge fa58ce343ad498196d799a7381869e79938e952a...

@bors
Copy link
Collaborator

bors commented Apr 24, 2025

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing fa58ce3 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 24, 2025
@bors bors merged commit fa58ce3 into rust-lang:master Apr 24, 2025
7 checks passed
@rustbot rustbot added this to the 1.88.0 milestone Apr 24, 2025
Copy link

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 differences

Show 134 test diffs

134 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard fa58ce343ad498196d799a7381869e79938e952a --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. x86_64-apple-2: 4955.8s -> 3888.9s (-21.5%)
  2. dist-x86_64-apple: 10084.1s -> 8480.5s (-15.9%)
  3. dist-aarch64-apple: 5197.0s -> 5840.1s (12.4%)
  4. dist-x86_64-linux: 5057.5s -> 5606.1s (10.8%)
  5. dist-arm-linux: 5355.5s -> 5839.8s (9.0%)
  6. dist-x86_64-mingw: 8157.6s -> 7444.0s (-8.7%)
  7. x86_64-apple-1: 9455.9s -> 8658.0s (-8.4%)
  8. dist-ohos: 9786.6s -> 10609.3s (8.4%)
  9. dist-i686-mingw: 8660.5s -> 8055.6s (-7.0%)
  10. aarch64-apple: 3851.1s -> 4084.9s (6.1%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (fa58ce3): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This 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.

mean range count
Regressions ❌
(primary)
0.2% [0.1%, 0.4%] 25
Regressions ❌
(secondary)
0.4% [0.1%, 0.6%] 48
Improvements ✅
(primary)
-0.2% [-0.2%, -0.2%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.2% [-0.2%, 0.4%] 26

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.

mean range count
Regressions ❌
(primary)
1.9% [0.5%, 2.9%] 3
Regressions ❌
(secondary)
2.0% [1.6%, 2.3%] 5
Improvements ✅
(primary)
-2.1% [-3.8%, -0.4%] 2
Improvements ✅
(secondary)
-4.1% [-8.0%, -1.4%] 6
All ❌✅ (primary) 0.3% [-3.8%, 2.9%] 5

Cycles

Results (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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.6% [-0.6%, -0.5%] 4
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.6% [-0.6%, -0.5%] 4

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 775.888s -> 775.233s (-0.08%)
Artifact size: 365.06 MiB -> 365.14 MiB (0.02%)

@nnethercote
Copy link
Contributor

TODO: write description

lol, lmao

@lcnr
Copy link
Contributor

lcnr commented Apr 24, 2025

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.

@compiler-errors
Copy link
Member Author

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.

@compiler-errors compiler-errors deleted the stall-generators branch April 24, 2025 19:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) F-autodiff `#![feature(autodiff)]` merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

normalizing in writeback causes cycle errors with generators
7 participants