ICE: OutputTypeParameterMismatch in failing to resolve associated type as tuple.

[rphmeier]

I honestly don't really know how to describe this one.
On stable the uncommented version works as expected, although it yields an ICE on both Beta and Nightly.

On all three release channels, the commented portion of the code fails to resolve
<(PhantomData<A>, PhantomData<B>, PhantomData<C>) as Foo<'a>>::Item as (&'a A, &'a B, &'a C), although they are the same type.

use std::marker::PhantomData;

trait Foo<'a> {
    type Item: 'a;

    fn consume<F>(self, f: F) where F: Fn(Self::Item);
}

fn get<T>() -> T { unimplemented!() }

impl<'a, A: 'a, B: 'a, C: 'a> Foo<'a> for 
(PhantomData<A>, PhantomData<B>, PhantomData<C>) {
    type Item = (&'a A, &'a B, &'a C);

    fn consume<F>(self, f: F) where F: Fn(Self::Item) {
        f(get());
    }
}

#[derive(Clone)]
struct Wrap<T> {
    foo: T,
}

impl<T: for<'a> Foo<'a>> Wrap<T> {
    fn consume<F>(self, f: F) where F: for<'a> Fn(<T as Foo<'a>>::Item) {
        self.foo.consume(f);
    }
}

fn drop3<A, B, C>(_: A, _: B, _: C) {}

fn main() {
    let foo = (PhantomData::<u32>, PhantomData::<f32>, PhantomData::<i32>);
    let wrap = Wrap {
        foo: foo
    };

    wrap.clone().consume(|item| {
        let (a, b, c) = item;
        drop3(a, b, c);
    });

    // uncomment to break
    // wrap.consume(|(a, b, c)| drop3(a, b, c));
}

The expected behavior is that I should be able to call wrap.consume() and match on the argument as a tuple. Note that without the indirection through "Wrap", this works as expected. In my program, the wrapper does more work which cannot be stripped away.
playground: http://is.gd/EYtNFj

[Aatch]

Removing the higher-ranked lifetimes appears to make it work. Interestingly, the MIR typecheck seems to be picking up the error indirectly, as the warnings disappear once that is fixed.

This is still a bug, but changing the Wrap inherent impl to this:

impl<'a, T: Foo<'a>> Wrap<T> {
  fn consume<F>(f: F) where F: Fn(<T as Foo<'a>>::Item) {
    self.foo.consume(f);
  }
}

works.

I assume the reason is that there's no link between the lifetime in the bound on F and the one in the impl signature, my guess is that one part of the compiler is allowing it, but another part is expecting the lifetimes to match up, which is the source of the error.

The error in the case where your destructing in the parameter list is correct, though not very helpful.

[rphmeier]

Could you elaborate on why you believe the error message to be correct? It is my understanding that you can destructure tuples in a function or closure's argument list. This function is accepting a tuple as the argument but is not allowing destructuring within the argument list.

[Aatch]

@rphmeier ah, I was focussed on the error and missed the fact that the first case works on stable. It's not about whether or not you can or can't destructure in an argument list (you can). The error is about a type-mismatch. The use of higher-ranked lifetimes here isn't correct, and causes the types not match. Why the let-destructuring works on stable is beyond me though.

[nikomatsakis]

triage: P-high

[pnkfelix]

This may have been obvious to others, but just to confirm: reproducing the issue described does not require using a 3-tuple. A 1-tuple (A,) does suffice.

However, the behavior changes in a subtle manner if you try to go all the way to removing the tuple entirely (e.g. impl<'a, A: 'a> Foo<'a> for PhantomData<A> and type Item = &'a A;), then on stable, the commented and uncommented code both compile, while the nightly compiler still has a warning about broken MIR.

[pnkfelix]

Nominating; I currently agree with @Aatch's analysis that the original code should (probably) have been rejected by the compiler, but I am not clear on what the appropriate course of action is to take this time.

Namely, we are currently in a situation where we are both emitting a warning from mir typecheck, and then subsequently erroring during trans::collector due to

Encountered error OutputTypeParameterMismatch(Binder(<[closure] as Fn<(<(PhantomData<u32>,) as Foo<'a>>::Item,)>>), Binder(<[closure] as Fn<((&'static u32,),)>>), Sorts(ExpectedFound { expected: (&'static u32,), found: <(PhantomData<u32>,) as Foo<'_>>::Item })) selecting Binder(<[closure] as Fn<((&'static u32,),)>>) during trans

So my question is: Should we either:

1. Figure out how to get the trans::collector to stop erroring in this case, or
2. Treat this scenario as an error in the source program
   • (i.e. either promote the MIR typeck warning to an error, or figure out a way to detect this scenario outside of MIR typeck)

[pnkfelix]

Here is a gist of a somewhat reduced version of the issue:
https://gist.github.com/pnkfelix/74440e047d26c0a410ce5fc74204962c

notably, it is set up so that you can pass --cfg removal_1 and/or --cfg removal_2 to observe the ICE going away.

I said earlier that the original code probably should have been rejected, but the more I look at this, the more uncertain I become about that claim. (To me it comes down to a question of whether the impl's precondition of having a T: for <'a> Foo<'a> means that it is correct to use that T in the context of for <'b> Fn(<T as Foo<'b>>::Item))

[rphmeier]

Thanks for looking into this @pnkfelix -- I'm not particularly knowledgeable about the intricacies of HRTBs, but my intuition when I was writing this code went as like this:
Verify that for all 'a, T implements Foo<'a>
Pass a function which can accept, for all 'a, Foo<'a>::Item.
Call the function using Foo<'a> for some anonymous yet valid 'a.
So far, this seems mostly ok. My understanding of the situation begins to fall apart here. In actuality, the type of T as Foo<'a> item is only altered w.r.t. 'a itself. However, since it could technically be possible for Foo<'static>::Item to be completely different than Foo<'a>::Item rather than the two having some kind of subtyping relationship, this begins to verge into the category of general HKT, which is not supported at all.
In that sense, I think that this should be classified as a bug, although I am not familiar with the compiler implementation details.

[nikomatsakis]

So I looked into this. My feeling is that the underlying problem here is that we do not attempt to normalize under a higher-ranked binder -- this is why (e.g.) stable fails to understand the argument type. This is definitely a pre-existing issue (and there are a number of open issues related to it), but I'm not sure why we started to ICE when we did not before.