Use fulfillment in method probe, not evaluation#122317
Use fulfillment in method probe, not evaluation#122317bors merged 6 commits intorust-lang:masterfrom
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
|
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_predicatecalls, 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