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.