-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Make can_eq
process obligations (almost) everywhere
#127172
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…re, r=<try> Make `can_eq` process obligations (almost) everywhere r? lcnr
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (65614b9): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking 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. @bors rollup=never 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)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 696.099s -> 696.897s (0.11%) |
HIR ty lowering was modified cc @fmease |
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.
can_eq_shallow
only exists for error reporting in rustc_infer
, does it? Looking at it for just a few minutes... we should move all of that code into rustc_trait_selection
, shouldn't we?
I don't mind doing that after this PR and modifying the fixme, but we already have some weird hacks in the TypeErrCtxt
which feel like they should be unnecessary 🤔
}; | ||
ocx.select_where_possible().is_empty() | ||
}) | ||
}; |
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.
does wfcx.eq
ever fail when can_eq_self
returns true? I feel like it can#t and all this code should just use commit_if_ok
🤔 could be a followup
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.
Ok, I just did it in this PR. You should probably read it and convince yourself it's correct, since I did kinda simplify a lot of the control flow which was redundant.
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.
alright, after my comment in wfcheck
, r=me
c09d9dc
to
3239713
Compare
|
||
// Without `feature(arbitrary_self_types)`, we require that `receiver_ty` implements `Receiver`. | ||
if !arbitrary_self_types_enabled | ||
&& !receiver_is_implemented(wfcx, receiver_trait_def_id, cause.clone(), receiver_ty) |
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 am very confused by the previous control flow here:
if auto-deref steps returns None
and a type still implemented the receiver trait, it was fine? That feels undesirable. receiver_is_implemented
could also be converted to a commit_if_ok
🤔 not sure how that impacts diagnostics though
r=me with or without that change
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.
If autoderef returns None
then it went into the else
branch of the if-let and returned false
.
It shouldn't affect diagnostics, since we're still registering the receiver trait, though I don't think it does much since it's a single root obligation
Don't think it's worth changing the receiver check rn, since it's just a single trait bound so it doesn't really have the same benefit as doing @bors r=lcnr |
☔ The latest upstream changes (presumably #127261) made this pull request unmergeable. Please resolve the merge conflicts. |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
3239713
to
465e7d5
Compare
@bors r+ rollup=never |
☀️ Test successful - checks-actions |
Finished benchmarking commit (89aefb9): 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)Results (primary 2.1%)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 -2.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: 699.951s -> 699.119s (-0.12%) |
…, r=<try> Revert "Rework receiver_is_valid" This reverts commit 465e7d5. Testing perf: rust-lang#127172 (comment) r? `@ghost`
…, r=<try> Revert "Rework receiver_is_valid" This reverts commit 465e7d5. Testing perf: rust-lang#127172 (comment) r? `@ghost`
…, r=<try> Revert "Rework receiver_is_valid" This reverts commit 465e7d5. Testing perf: rust-lang#127172 (comment) r? `@ghost`
Small regressions across various benchmarks. Not marking as triaged yet, although it seems like #127473 could claw some of the perf. back. |
Move
can_eq
to an extension trait onInferCtxt
inrustc_trait_selection
, and change it so that it processes obligations. This should strengthen it to be more accurate in some cases, but is most important for the new trait solver which delays relating aliases toAliasRelate
goals. Without this, we always basically just return true when passing aliases tocan_eq
, which can lead to weird errors, for example #127149.I'm not actually certain if we should have
can_eq
be called on the good path. In cases where we needcan_eq
, we probably should just be using a regular probe.Fixes #127149
r? lcnr