Peculiar lifetime bound required error avoidable via &ref x

[huonw]

#[allow(dead_code)]
fn make<'a, A: Clone, I: Iterator<&'a A>>(mut it: I) -> Vec<A> {
    let mut v = vec![];
    for a in it {
        v.push(a.clone())
    }
    v
}

fn main() {}

fails to compile with

<anon>:4:9: 4:10 error: the parameter type `A` may not live long enough; consider adding an explicit lifetime bound `A:'a`...
<anon>:4     for a in it {
                 ^
<anon>:4:9: 4:10 note: ...so that the reference type `&'a A` does not outlive the data it points at
<anon>:4     for a in it {
                 ^
<anon>:5:16: 5:17 error: the parameter type `A` may not live long enough; consider adding an explicit lifetime bound `A:'a`...
<anon>:5         v.push(a.clone())
                        ^
<anon>:5:16: 5:17 note: ...so that the reference type `&'a A` does not outlive the data it points at
<anon>:5         v.push(a.clone())
                        ^

changing the declaration of A to include 'a as a bound makes it compile, as does changing the for loop to for &ref a in it { ... }. It seems somewhat peculiar that this noop re-referencing pattern silences the error (filing a bug because I'm concerned by the possibility that the pattern isn't being handled correctly, it may be all alright).

cc @nikomatsakis

[nikomatsakis]

I think this is due to the fact that for loops are no longer desugar into match code with a loop. It is peculiar but probably harmless. What happens is that the iterator yields up refs of lifetime 'a, so in the original code x has type &'a A, but there is no rule that says that A:'a (actually I think we ought to infer that from the trait bound on I, but we do not currently do so). Adding the bound explicitly resolves that, as you said.

In the rewritten code, &ref x causes the lifetime of x to be inferred separately, and yields a shorter lifetime that is local to the loop (let's call it 'loop). Hence the type of x is &'loop A. The compiler always assumes that type arguments outlive the function body itself, so A:'loop is considered to be true.

However, in principle the for loop ought to check that the type that the pattern is matching against is also well-formed. If the code were written out using a match, for example, this check would occur.

[steveklabnik]

Updated code:

#[allow(dead_code)]
fn make<'a, A: Clone, I: Iterator<Item=&'a A>>(mut it: I) -> Vec<A> {
    let mut v = vec![];
    for a in it {
        v.push(a.clone())
    }
    v
}

fn main() {}

Given that this seems like a niche thing that nobody else has commented on in a year, is this a WONTFIX?

[arielb1]

@steveklabnik

I think we should add "implicator bounds" from all predicates. We do basically check them every place that matters, but I won't be completely surprised if you could do something evil via trait matching.

[arielb1]

In fact, in new versions of Rust this code gives a WF warning even without the loop.

[huonw]

Seems fixed.