Associated type regression? unable to infer enough type information about `_`

[arcnmx]

rustc seems to accept this under stable, but not beta or nightly.

playpen repro

trait T {
    type T;
}

struct S;
impl T for S {
    type T = S;
}

trait T2 {
    type T: Iterator<Item=<S as T>::T>;
}

error: unable to infer enough type information about `_`; type annotations or generic parameter binding required

[arielb1]

This is the ParamCandidate vs. ProjectionCandidate issue in project rather than in select. Should we do the "just pick the where-clause" thing here too? cc @nikomatsakis

Maybe just apply them all (and enjoy the type-errors on inconsistency) if there are no inference variables - as select will happily deal with these?

[nikomatsakis]

@arielb1

This is the ParamCandidate vs. ProjectionCandidate issue in project rather than in select. Should we do the "just pick the where-clause" thing here too? cc @nikomatsakis

I suppose we ought to, yes, for consistency. I imagine the same forces that favor where clauses (helping along inference) will play out here too.

[brson]

This will hit stable in a little over a week.

[brson]

cc @rust-lang/compiler @rust-lang/lang

[nikomatsakis]

It's not as simple as preferring where-clauses over impls. There are in fact two relevant where-clauses included in the environment, one with <S as Trait>::T (unnormalizd) and one with just S. I'm not sure where the duplicate comes from, investigating.

[nikomatsakis]

I think the problem derives from the fact that assemble_candidates_from_trait_def does not normalize.

[nikomatsakis]

(Also, this is caused by the RFC 1214 changes, which are checking for WF'd-ness, which is where the error occurs.)

[nikomatsakis]

So, while this example is a regression, the underlying problem is pre-existing. For example, this test case shows the same conflict (note that the compilation error goes away if you change <S as T>::T in the trait definition to S, even though those ought to be the same). I'm not sure of the best fix overall, honestly, though lazy normalization as I've been envisioning it could help here (but you'd have to add in a policy of "apply all applicable where clauses", which is perhaps fairly sane, modulo inference). I can imagine some shorter-term hacky fixes, which I will investigate, but it may also make sense to accept this regression as a pre-existing shortcoming of normalization (albeit one exacerbated by other bugfixes).

@arcnmx I am curious whether you have some larger context for this minified example.

[arielb1]

@nikomatsakis

I was thinking of just picking all where-clauses and projections when there are no inference variables involved. "guessing" in projections is stupid anyway.

[arielb1]

@nikomatsakis

projection just uses ParamEnv for its equivalent of ProjectionCandidate. This still won't help if the candidates are mostly the same. The code handles projections pretty idiotically, however.

I would prefer that we make projection not generate unneeded candidates - a projection predicate should always be coupled with some proof of the relevant selection predicate holding.

[nikomatsakis]

@arielb1 certainly just converting to use ProjectionCandidate -- and then give ParamEnv priority -- would be a relatively simple solution to the immediate problem. I'm not sure I understood this comment:

I would prefer that we make projection not generate unneeded candidates - a projection predicate should always be coupled with some proof of the relevant selection predicate holding.

Do you mean that we should fully evaluate all nested obligations? This isn't always possible if there are inference variables, of course.