-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Check projection predicates satisfy bounds #79543
Check projection predicates satisfy bounds #79543
Conversation
This restores the behavior from before rust-lang#73905.
So, failure is due to problems like this: trait T {
type Item;
fn f() where Self: T<Item = str> {}
} This is allowed on stable because the trait has a |
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 looks good, although I do have a question
traits::Obligation::new( | ||
wf.cause(traits::BindingObligation(t.projection_ty.item_def_id, span)), | ||
param_env, | ||
bound.subst(infcx.tcx, t.projection_ty.substs), |
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.
So -- where I got stuck here was that I assumed we would need to normalize after substitution. Does that happen elsewhere?
(I still feel like (not in this PR...) I'd like to explore having the "bounds" predicate return a Binder<Predicate>
, with the binder being the "self" type.)
So @matthewjasper -- we had discussed the possibility of including associated type bounds in elaboration. However, I'm not sure if that's really a good idea. I guess we ought to carve out some space to have a longer conversation about the implications of accepting this change. |
Or, by that I mean: the implications of doing nothing about the change in semantics, because that is a tempting option. |
(Note for future prioritization visits: to be clear, we cannot land the PR as it stands now, because it literally breaks bootstrapping of rustc.) |
closing, I think that we're going to accept the change in behaviour |
This restores the behavior from before #73905.
closes #78893
r? @nikomatsakis