Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HIR printing of async fn is broken #60661

Open
oli-obk opened this issue May 9, 2019 · 7 comments
Open

HIR printing of async fn is broken #60661

oli-obk opened this issue May 9, 2019 · 7 comments

Comments

@oli-obk
Copy link
Contributor

@oli-obk oli-obk commented May 9, 2019

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
Copy link
Member

@cramertj cramertj commented May 9, 2019

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
Copy link
Contributor Author

@oli-obk oli-obk commented May 10, 2019

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

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
Copy link
Member

@cramertj cramertj commented May 10, 2019

@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
Copy link
Contributor Author

@oli-obk oli-obk commented May 11, 2019

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
Copy link
Member

@cramertj cramertj commented May 11, 2019

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
Copy link
Member

@Mark-Simulacrum Mark-Simulacrum commented Sep 22, 2019

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

@eddyb
Copy link
Member

@eddyb eddyb commented Jul 27, 2021

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).

@eddyb eddyb reopened this Jul 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants