Error with nested async fn and anonymous lifetimes

[udoprog]

The following breaks on nightly (see playground)

#![feature(async_await)]

struct Foo<'a>(&'a ());

impl Foo<'_> {
    fn test() {
        async fn test() {}
    }
}

With:

error[E0261]: use of undeclared lifetime name `'_`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0261`.
error: Could not compile `playground`.

To learn more, run the command again with --verbose.

CC: dtolnay/async-trait#18

[Centril]

Reduced:

#![feature(async_await)]

struct Foo<'a>(&'a ());

impl<'a> Foo<'a> {
    fn test() {
        async fn test() {}
    }
}

[udoprog]

Forgot to mention in case this helps, giving the inner fn a matching lifetime avoids this issue for some reason:

#![feature(async_await)]

struct Foo<'a>(&'a ());

impl<'a> Foo<'a> {
    fn test() {
        async fn test<'a>() {}
    }
}

[cramertj]

The reason this is happening is that the desugared version of async fn applies all in-scope lifetimes to the returned existential type, which in this case is creating -> Fut<'_>, which is invalid. I'm not sure exactly what the best fix is for this, though, since elided lifetimes in the impl signature are intentionally unnameable. The closest idea I have would be to create some special new lifetime that is '_ but can refer to lifetimes originating from the impl header. cc @nikomatsakis who may have opinions.

[nikomatsakis]

Hmm @cramertj wouldn't you expect the nested async fn to not inherit anything from its enclosing scopes? Seems like a bug to me that it does? Am I confused about something?

[cramertj]

@nikomatsakis The function in the middle is actually a bit of a source of confusion here, although it does indicate that there's a second bug since we shouldn't be inheriting generics since the nested async fn isn't part of the impl.

The bug I was focusing on is better illustrated by this example:

#![feature(async_await)]

struct Foo<'a>(&'a u8);

impl Foo<'_> {
    async fn bar() {}
}

which produces this error:

error[E0261]: use of undeclared lifetime name `'_`

error: aborting due to previous error

This is because the code is transformed into

impl Foo<'_> {
    fn bar() -> OpaqueTy<'_> {}
}

and in that case '_ does not refer back to the usage from the impl header.

[nikomatsakis]

@cramertj I see. Indeed, I would expect that, internally, we'd have some way to refer back to the '_ from the impl header. I believe this should be possible, no? In particular, the '_ in impls expands (internally) to LifetimeName::Param(ParamName::Fresh(N)) for some integer N, which I believe is basically treated like any other named lifetime.

[cramertj]

@nikomatsakis Yep, I would've expected so as well-- I'm not sure why that isn't working, I'd have to take a look.

[nikomatsakis]

@cramertj I was looking and I think the bug lies here:

rust/src/librustc/hir/lowering.rs

Lines 2267 to 2272 in c01be67

	let lifetime_params: Vec<(Span, ParamName)> =
	this.in_scope_lifetimes
	.iter().cloned()
	.map(|ident| (ident.span, ParamName::Plain(ident)))
	.chain(this.lifetimes_to_define.iter().cloned())
	.collect();

Probably in_scope_lifetimes needs to be a Vec<ParamName> instead, or we need to use something else for this purpose.

[nikomatsakis]

A closer reading suggests I was mistaken. The '_ lifetimes from the impl should show up in lifetimes_to_define -- in_scope_lifetimes includes only the explicitly declared lifetimes written by the user on the impl. I'm not quite sure what the problem is yet.

[nikomatsakis]

OK, no, I was correct. When processing impl items, we convert the '_ lifetimes into in_scope_lifetime entries.

EDIT: Er, I'm still not entirely sure. Reading more. =)

[nikomatsakis]

OK, I have a fix for the async fn method issue, but not the nested async fn item issue.

[nikomatsakis]

I forked off #63500 for the method issue

[nikomatsakis]

@cramertj I didn't prep a fix for this one yet. It seems obvious that some internal state is not being reset when we enter a new item.

[nikomatsakis]

but if you have a chance to investigate, would be appreciated

[nikomatsakis]

Presumably the problem is that visit_item doesn't "reset" the in_scope_lifetimes vector -- it only seems to extend it...

rust/src/librustc/hir/lowering/item.rs

Line 70 in c01be67

self.lctx.with_parent_item_lifetime_defs(hir_id, |this| {

[nikomatsakis]

Indeed, in-band lifetimes are broken in the same way. This fails to compile (playground):

#![feature(in_band_lifetimes)]

struct Foo<'a> {
    x: &'a u32
    
}

impl Foo<'a> {
    fn method(&self) {
        fn blah(f: Foo<'a>) { }
    }
}

[nikomatsakis]

Working on a possible fix

[nikomatsakis]

Yep, have a fix.

[Mark-Simulacrum]

Inband lifetimes looks similar to #52532 fwiw

[nikomatsakis]

@Mark-Simulacrum thanks