HIR printing of `async fn` is broken

[oli-obk]

async fn foo(_: &u8) {}

expanded with rustc --edition 2018 -Z unpretty=hir yields

async fn foo<'_>(__arg0: &'_ u8)
 ->
      ::std::future::from_generator(move ||
                                        {
                                            let __arg0 = __arg0;
                                            let _ = __arg0;
                                        })

which is not correct. We should drop the async, give a return type and print some {} around the function body.

cc @cramertj

[cramertj]

printing this is going to be kind of odd given that the HIR-equivalent would be to use existential type but with strange generics parenting. What do we do for impl Trait here?

[oli-obk]

That seems to be the problem :D we don't do anything:

rust/src/librustc/hir/print.rs

Line 396 in 407536e

hir::TyKind::Def(..) => {},

Ok, so for any implementor: we need to emit impl followed by the bounds instead of doing nothing as shown above. The bounds can be printed like https://github.com/rust-lang/rust/blob/master/src/librustc/hir/print.rs#L650-L660 just without the :. Maybe pull out that piece of code into a function.

Note that while TyKind::Def contains a hir::Item, the ItemKind of that Item can only be Existential, you can just bug! out for the other variants.

[cramertj]

@oli-obk even if you do that, it still won't compile: the code that async fn desugars to can't be written with impl Trait today because of how it captures multiple lifetimes that don't appear in the bound.

[oli-obk]

You can use something like the Captures trait to emulate that, right? https://doc.rust-lang.org/nightly/nightly-rustc/rustc/util/captures/trait.Captures.html

[cramertj]

Yeah, but we don't expose anything like that in std today, so you'd have to add it to the lowered crate...

[Mark-Simulacrum]

I'm going to close this since I think this is not a bug. See also #60663.

[eddyb]

I'm going to close this since I think this is not a bug. See also #60663.

I disagree (and am reopening because of that) - #60663 may not be a bug, but not showing anything, not even some non-Rust pseudosyntax, is a bug.

One fun thing we could do if you want e.g. rustfmt to work, is to use macro syntax (I was thinking k# as well once that's supported but I doubt rustfmt would allow any custom syntax involving that).

So e.g. HIR!(LangItem("from_generator"))(...) instead of #[lang = "from_generator"](...) (which is how ::std::future::from_generator(...) gets printed nowadays, another regression observable through async fns).