-
Notifications
You must be signed in to change notification settings - Fork 13k
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
split NormalizesTo
out of Projection
#112658
Conversation
@@ -112,6 +110,9 @@ pub(super) trait GoalKind<'tcx>: | |||
// Consider a clause, which consists of a "assumption" and some "requirements", | |||
// to satisfy a goal. If the requirements hold, then attempt to satisfy our | |||
// goal by equating it with the assumption. | |||
// | |||
// FIXME: change this function to take an actual `Clause` as assumption instead | |||
// of a predicate. |
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 don't think we should land this without first separately handling that FIXME.
With NormalizesTo
as a goal getting proven by Projection
in the environment it's otherwise far too easy to accidentally put a NormalizesTo
into the environment which is useless. Even without bugs from this, it is still very confusing.
This comment has been minimized.
This comment has been minimized.
Err(NoSolution) | ||
} | ||
let alias = goal.predicate.projection_ty.to_ty(self.tcx()).into(); | ||
self.eq(goal.param_env, alias, goal.predicate.term)?; |
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.
should we skip all the nonsense and just emit an alias-eq here directly?
Well, actually, I guess this does behave differently on alias projection ?0
now 🤔
ce1d66b
to
5f71900
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
with this the following example currently fails: fn foo(i: isize) -> isize { i + 1 }
fn apply<A, F>(f: F, v: A) where F: FnOnce(A) -> A { f(v); }
pub fn main() {
apply(foo, 2)
} the reason is that we try to prove I think that to fix this we can either change the generalizer to emit |
Huh, that's exactly the problem I ran into with Chalk :) |
☔ The latest upstream changes (presumably #108860) made this pull request unmergeable. Please resolve the merge conflicts. |
@rustbot author |
…3, r=BoxyUwU split `NormalizesTo` out of `Projection` 3 third attempt at rust-lang#112658. Rebasing rust-lang#116262 is very annoying, so I am doing it again from scratch. We should now be able to merge it without regressing anything as we handle occurs check failures involving aliases correctly since rust-lang#117088. see https://hackmd.io/ktEL8knTSYmtdfrMMnA-Hg fixes rust-lang/trait-system-refactor-initiative#1 r? `@compiler-errors`
implementing solution 3 of https://hackmd.io/noGGefTfQ0eCARFb3D0tJw to fix rust-lang/trait-system-refactor-initiative#1
r? @compiler-errors