type inference doesn't work in async fn that return Box<dyn SomeTrait>

[macpp]

i have following fn that works completly fine:

pub fn test1() -> Box<dyn Debug> {
    Box::new("asdf")
}

if i try trivialy make it async just by adding async keyword i get build error:

error[E0271]: type mismatch resolving `<impl core::future::future::Future as core::future::future::Future>::Output == std::boxed::Box<(dyn std::fmt::Debug + 'static)>`
  --> comix_downloader_lib_async/src/lib.rs:49:25
   |
49 | pub async fn test1() -> Box<dyn Debug> {
   |                         ^^^^^^^^^^^^^^ expected &str, found trait std::fmt::Debug
   |
   = note: expected type `std::boxed::Box<&str>`
              found type `std::boxed::Box<(dyn std::fmt::Debug + 'static)>`
   = note: the return type of a function must have a statically known size

i can work around this by defining types of variables explicitly:

pub async fn test3() -> Box<dyn Debug> {
    let tmp : Box<dyn Debug> = Box::new("asdf");
    tmp
}

but for obvious reasons this is not as nice as sync version
maybe related to #60414 ?

rustc --version : rustc 1.36.0-nightly (00859e3e6 2019-04-29)

[cramertj]

I'd put this under a similar camp as #54326 -- the issue here is that we need to fix the output of the Future to the return type as provided, rather than trying to infer it from the context (which isn't smart enough in this case to see that a trait object coercion is required).

[cramertj]

Related to #54326, some discussion in https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async-foundations/topic/mismatched.20types.20diag.20.2354326/near/168076272.

[nikomatsakis]

Discussed in meeting today. Adding the "unclear" tag: this one is tricky to fix and it's not clear that it should block stabilization. It would definitely be good to have, though. In particular, it seems unlikely to be a forwards compatibility issue, since this is basically a problem of failing to do the coercion that is needed and hence getting more compilation errors (but it would be helpful if people have counterexamples in mind where behavior might change, seems possible).

[nikomatsakis]

Discussed in the rust-lang/lang meeting -- we decided this is, ultimately, not a blocker but we ought to "try real hard" to fix it.

[leo60228]

This even more minimal example has the same problem:

async fn func(s: &str) -> &[&str] {
    &[s]
}

[cramertj]

@leo60228 Yup, you need

async fn func(s: &str) -> &[&str] {
    &[s] as &[&str]
}

which correctly generates an error:

error[E0515]: cannot return value referencing temporary value
 --> src/lib.rs:2:5
  |
2 |     &[s] as &[&str]
  |     ^---^^^^^^^^^^^
  |     ||
  |     |temporary value created here
  |     returns a value referencing data owned by the current function

[leo60228]

@cramertj Whoops, I didn't test the non-async version... This does have the problem I intended to demonstrate, though:

async fn func() -> &'static [&'static str] {
    &["hi"]
}

[blitzerr]

@nikomatsakis Any notes on this one ?

[nikomatsakis]

OK, so I have been doing a bit of digging into this. Our previous efforts to fix those were focused on keeping the existing desugaring. But @Centril was suggesting that we should modify the HIR and I think they are correct.

Let's walk through what happens here. First off, I'll run with this example:

async fn func() -> &'static [&'static str] {
    &["hi"]
}

This presently gets desugared to an async block, but in the compiler that async block is itself desugared into a call to from_generator with a "generator closure" as argument:

fn func() -> &'static [&'static str] {
  ::std::future::from_generator(gen || {
    &["hi"]
  })
}

I think what we want to do, in short, is to generate a return type annotation on that generator. You can see that this will fix the compile error in this manually desugared version from the playground.

However, I think the right way to do this is probably to extend the HIR type with some kind of "current function return type" node for internal use that expands to the return type from the current function. The reason to do this is that we can't just "copy-n-paste" the return type from the function declaration into this position -- the references to lifetimes will not work out correctly, unfortunately. In particular, elided lifetimes are handled by a later pass and they would be treated differently in this position.

A few more tips. This desugaring is done here:

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

Lines 1223 to 1258 in c7bc0bf

	let async_expr = this.make_async_expr(
	CaptureBy::Value, closure_id, None, body.span,
	|this| {
	// Create a block from the user's function body:
	let user_body = this.lower_block_expr(body);
	// Transform into `drop-temps { <user-body> }`, an expression:
	let desugared_span = this.mark_span_with_reason(
	DesugaringKind::Async,
	user_body.span,
	None,
	);
	let user_body = this.expr_drop_temps(
	desugared_span,
	P(user_body),
	ThinVec::new(),
	);
	// As noted above, create the final block like
	//
	// ```
	// {
	// let $param_pattern = $raw_param;
	// ...
	// drop-temps { <user-body> }
	// }
	// ```
	let body = this.block_all(
	desugared_span,
	statements.into(),
	Some(P(user_body)),
	);
	this.expr_block(P(body), ThinVec::new())
	});
	(HirVec::from(parameters), this.expr(body.span, async_expr, ThinVec::new()))
	})

This is a call to make_async_expr. Note the 3rd argument, ret_ty, in particular:

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

Line 451 in c7bc0bf

ret_ty: Option<AstP<Ty>>,

This argument supplies the return type annotation on the closure. When we invoke it from async fn, it is None. We can't just supply Some, however, because this expects an AST type and we would want to give it a HIR type, I think, at least if we're going to be adding some special HIR node representing the "return type of the current function". I have to dig a bit into this part, another option might be to try and convince the lifetime elision code to do the right thing so that we can just copy-and-paste the type.

[nikomatsakis]

Ah, actually, I realize something even easier. We already supply a flag to the generator code that indicates this is a generator. If we supply a flag that indicates that this is the "async move from an async fn body", we could supply the correct typing hints in type-check.

[nikomatsakis]

I may take a stab at this in a few, else I'll poke somebody to give it a try in Zulip.

[nikomatsakis]

Oh dang it, I just realized the obvious complication -- the return type of the function is actually a future, so what we really need to do is to extract the Output of that. This is going to be an annoying amount of code, though it remains plausible.

[cramertj]

I'm sure this has already been considered, but this bug would be trivially fixable if it were possible to have types from the AST appear twice in the HIR. It also seems plausible that such a thing would be useful elsewhere. Is there a sensible path to allowing this?

[nikomatsakis]

Got a pending fix in #64999