Repository navigation
Conversation
This comment has been minimized.
This comment has been minimized.
3b6a914 to
09d4b1d
Compare
This comment has been minimized.
This comment has been minimized.
09d4b1d to
f3d3688
Compare
|
r? @mu001999 rustbot has assigned @mu001999. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
@rustbot reroll |
|
@rustbot reroll |
|
r? types |
f3d3688 to
7280045
Compare
This comment has been minimized.
This comment has been minimized.
cdce223 to
d34f701
Compare
This comment has been minimized.
This comment has been minimized.
d34f701 to
32a25b8
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Signed-off-by: Amirhossein Akhlaghpour <m9.akhlaghpoor@gmail.com>
Signed-off-by: Amirhossein Akhlaghpour <m9.akhlaghpoor@gmail.com>
32a25b8 to
5cb7028
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
Signed-off-by: Amirhossein Akhlaghpour <m9.akhlaghpoor@gmail.com>
|
r? lcnr |
|
this fix feels odd to me. I would assume us to instead split member constraints into a "complete" variant and a "non-complete" variant. But this is also interesting because different opaque type args can have different region assumptions in scope. I don't have the capacity to deeply engage with this, blocked on next-solver stabilization. |
|
☔ The latest upstream changes (presumably #163945) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
fixes rust-lang/trait-system-refactor-initiative#227
from what i understand the issue is that with the next solver we can get multiple hidden type candidates for what is effectively the same opaque instantiation but with fresh non-captured parent lifetimes. member constraints are currently applied to those candidates separately, so an unconstrained region can pick a valid but wrong lifetime before information from the other candidate is available. this changes the order a bit: compatible candidates are related first then RegionCtxt is rebuilt and member constraints are applied
non-member lifetime positions are replaced with fresh local NLL vars during that equality so we don't accidentally constrain regions that are supposed to be ignored. i'm not fully sure this is the best place to restore that behavior especially around how the candidates are grouped and feedback there would be appreciated