-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Use fulfillment in method probe, not evaluation #122317
Conversation
Some changes occurred in engine.rs, potentially modifying the public API of |
This comment has been minimized.
This comment has been minimized.
@bors try |
…, r=<try> Use fulfillment in method probe, not evaluation This PR reworks method probing to use fulfillment instead of a `for`-loop of `evaluate_predicate` calls, and moves normalization from method candidate assembly into the `consider_probe`, where it's applied to *all* candidates. This last part coincidentally fixes rust-lang#121643 (comment). Regarding *why* this large rewrite is done: In general, it's an anti-pattern to do `for o in obligations { evaluate(o); }` because it's not compatible with the way that the new solver emits alias-relate obligations which constrain variables that may show up in other predicates. Putting this up for vibe-check mostly. Tests aren't yet blessed, and there are some nuances about whether it's worthwhile to restore regressed diagnostics. r? lcnr
☀️ Try build successful - checks-actions |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
Crater rollup This is a crater rollup of: - [ ] rust-lang#122317 - [ ] rust-lang#122501 - [ ] rust-lang#122077 What does that mean? Well, I'm gonna run crater with p=3 on this PR, and then re-run *just* the list of failed crates on each PR. That should deduplicate the bulk of crates which we expect are unaffected by these PRs. Don't touch this PR please. r? `@ghost`
Crater rollup This is a crater rollup of: - [ ] rust-lang#122317 - [ ] rust-lang#122501 - [ ] rust-lang#122077 What does that mean? Well, I'm gonna run crater with p=3 on this PR, and then re-run *just* the list of failed crates on each PR. That should deduplicate the bulk of crates which we expect are unaffected by these PRs. Don't touch this PR please. r? `@ghost`
3702ab1
to
35d6003
Compare
@bors try |
…, r=<try> Use fulfillment in method probe, not evaluation This PR reworks method probing to use fulfillment instead of a `for`-loop of `evaluate_predicate` calls, and moves normalization from method candidate assembly into the `consider_probe`, where it's applied to *all* candidates. This last part coincidentally fixes rust-lang#121643 (comment). Regarding *why* this large rewrite is done: In general, it's an anti-pattern to do `for o in obligations { evaluate(o); }` because it's not compatible with the way that the new solver emits alias-relate obligations which constrain variables that may show up in other predicates. Putting this up for vibe-check mostly. Tests aren't yet blessed, and there are some nuances about whether it's worthwhile to restore regressed diagnostics. r? lcnr
☀️ Try build successful - checks-actions |
1 similar comment
☀️ Try build successful - checks-actions |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
☔ The latest upstream changes (presumably #124241) made this pull request unmergeable. Please resolve the merge conflicts. |
685ba72
to
8995c2c
Compare
@bors r+ rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (cd90d5c): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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 sizeResultsThis 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.
Bootstrap: 673.699s -> 674.88s (0.18%) |
checking perf in #124303 |
Marking this as triaged -- looks like attempts were made to improve performance in #124303 but did not pan out. The regressions are mostly pretty small with the exception of a stress test for exactly(?) this code. |
…=<try> Relate receiver invariantly in method probe for `Mode::Path` Reverts rust-lang#126128 Fixes the part of rust-lang#122317 which always used subtyping instead of eq Fixes rust-lang#126227 (TODO: test) WIP: description r? lcnr
This PR reworks method probing to use fulfillment instead of a
for
-loop ofevaluate_predicate
calls, and moves normalization from method candidate assembly into theconsider_probe
, where it's applied to all candidates. This last part coincidentally fixes #121643 (comment).Regarding why this large rewrite is done: In general, it's an anti-pattern to do
for o in obligations { evaluate(o); }
because it's not compatible with the way that the new solver emits alias-relate obligations which constrain variables that may show up in other predicates.r? lcnr