Lifetime issues with arguments to function calls that are awaited on

[alex]

I wasn't sure if this was a Rust bug, a futures-await bug, or a duplicate of one of the several other lifetime issues :-)

I've minimized this issue down to the following code:

#![feature(conservative_impl_trait, generators, proc_macro)]

extern crate futures_await as futures;

use futures::prelude::*;


fn f1<'a>(_: &'a [u8]) -> impl Future<Item=(), Error=()> + 'a {
    return futures::future::ok(());
}

#[async]
fn g1(v: Vec<u8>) -> Result<(), ()> {
    await!(f1(&v)).unwrap();
    Ok(())
}

fn f2(_: &[u8]) -> impl Future<Item=(), Error=()> {
    return futures::future::ok(());
}

#[async]
fn g2(v: Vec<u8>) -> Result<(), ()> {
    await!(f2(&v)).unwrap();
    Ok(())
}

f2/g2 using the default lifetimes compiles fine, however f1/g1 makes the compiler sad.

This was surprising to me, as I naively expected them to either both be accepted or both be rejected.

[alexcrichton]

Probably related to one of rust-lang/rust#44257, rust-lang/rust#44200, or rust-lang/rust#44197 perhaps?

[alex]

I suspect, if any of them I think it's most likely to be #44257, but I wasn't totally sure. The reason for my lack of confidence was that the behavior here varies based on whether there's an explicit lifetime or the automatic one.

[alexcrichton]

Yeah I'm not sure :(

Maybe let's see if this is still here after the upstream issues are fixed?

[alex]

Sounds like a plan :-)

[arielb1]

I believe rustc is correct here. f1 and f2 are different. Desugared, they have the signatures

fn f1<'a>(_: &'a [u8]) -> impl Future<Item=(), Error=()> + 'a;
fn f2<'a>(_: &'a [u8]) -> impl Future<Item=(), Error=()> + 'static;

This means that f1 can potentially capture its argument, while f2 can't. Because of that, v has to be borrowed over the await in g2, which isn't supported today.

[alexcrichton]

Ah excellent point, and thanks for the diagnosis @arielb1!