Skip to content

Conversation

matthewjasper
Copy link
Contributor

This restores the behavior from before #73905.

closes #78893

r? @nikomatsakis

This restores the behavior from before rust-lang#73905.
@matthewjasper matthewjasper added beta-nominated Nominated for backporting to the compiler in the beta channel. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 29, 2020
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 29, 2020
@matthewjasper
Copy link
Contributor Author

matthewjasper commented Nov 30, 2020

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 <Self as T>::Item: Sized predicate, which normalizes to str: Sized bound, making this code compile. On nightly/beta this predicate no longer exists.

Copy link
Contributor

@nikomatsakis nikomatsakis left a 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),
Copy link
Contributor

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.)

@spastorino
Copy link
Member

discussed in T-compiler meeting, declined to backport.

@rustbot modify labels: -beta-nominated

@rustbot rustbot removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Dec 3, 2020
@nikomatsakis
Copy link
Contributor

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.

@nikomatsakis
Copy link
Contributor

Or, by that I mean: the implications of doing nothing about the change in semantics, because that is a tempting option.

@pnkfelix
Copy link
Member

pnkfelix commented Dec 10, 2020

(Note for future prioritization visits: to be clear, we cannot land the PR as it stands now, because it literally breaks bootstrapping of rustc.)

@matthewjasper
Copy link
Contributor Author

closing, I think that we're going to accept the change in behaviour

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

No error reported when a generic parameter doesn't meet the requirement of an associated type
6 participants