-
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
WIP: eliminate DefineOpaqueTypes
by using Yes
across the compiler
#127034
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
.eq(DefineOpaqueTypes::No, placeholder_trait_predicate, candidate) | ||
.eq(DefineOpaqueTypes::Yes, placeholder_trait_predicate, candidate) |
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.
Let's discuss these in #127035
.eq(DefineOpaqueTypes::No, predicate.trait_ref, trait_ref) | ||
.eq(DefineOpaqueTypes::Yes, predicate.trait_ref, trait_ref) |
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.
This is used in selection (behind a probe) and confirmation. Without the previous commit skipping assemble_candidates_from_caller_bounds
for opaque types in their defining scope, this will cause functions like
rust/library/core/src/iter/adapters/filter.rs
Lines 73 to 78 in 127fa22
fn filter_fold<T, Acc>( | |
mut predicate: impl FnMut(&T) -> bool, | |
mut fold: impl FnMut(Acc, T) -> Acc, | |
) -> impl FnMut(Acc, T) -> Acc { | |
move |acc, item| if predicate(&item) { fold(acc, item) } else { acc } | |
} |
to immediately match the opaque type against the APIT with the same bounds.
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've looked into it a bit. Do you know of any fundamental issues with moving the old solver to a similar normalization scheme for opaques as the new solver uses? Or is that just a bad version of lazy norm?
pub fn recursive_fn<E>() -> impl Parser<E> { | ||
//[current]~^ ERROR: cycle | ||
move || recursive_fn().parse() | ||
//[next]~^ ERROR: type annotations needed | ||
//~^ ERROR: type annotations needed | ||
//[current]~| ERROR: no method named `parse` | ||
} |
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 guess we need to fix this issue for the new solver and the current one before we can land this commit
☔ The latest upstream changes (presumably #127172) made this pull request unmergeable. Please resolve the merge conflicts. |
2b1f439
to
513b139
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #125443) made this pull request unmergeable. Please resolve the merge conflicts. |
Opening this PR because
T: Trait
will match an-> impl Trait
whenverselect_where_possible
tries to solve some available bounds. This all happens before actually matching the opaque type to the returned value, at which point everything would work correctly, but obviously have issues with ordering). The next solver does not have this issue because it just converts opaque types to inference vars. Tho how it handles the send bounds in that case I do not know, will investigate.cc @lcnr @compiler-errors I'll open individual issues for things so we can keep separate things separate instead of talking about everything in this one big PR that I'll move out of WIP status when I can add a commit to that removes
DefineOpaqueTypes
.Related: