rustdoc renders re-exported `async fn`s incorrectly

[carllerche]

Relates to #58027, but this is the case where an async fn is re-exported by another crate. The docs for the original function shows async fn but the re-export shows fn -> impl Future.

Example:

• Original function
• Re-exported

[nikomatsakis]

Check-in from the triage meeting:

I'm going to mark this as "blocking" although it isn't really. It does seem like a good "polish" item to try and nail down before async-await hits beta, though it's ultimately a "nice to have".

[estebank]

Should we also consider _always_ documenting Fn() -> impl Future<Output=_> as async Fn() -> _?

[hirschenberger]

After some codereview I found that code.

There seems to be a reset of the asyncness when the function gets duplicated. Unfortunately I don't know from where I can get the asyncness information for hir::FnHeader there. There does not seem to be any information on that in sty::PolyFnSig.

[csmoe]

@rustbot claim

[nikomatsakis]

Mentoring instructions

Thanks, @hirschenberger, for the tip, I think that's exactly the right spot in the code. We basically want to copy the pathways in the code that we use for tracking (e.g.) whether a function is a const fn.

For that case, you can see in the code that we invoke the tcx query is_min_const_fn to check:

https://github.com/rust-lang/rust/blob/3287a65fc05028dce3b521765f4643384ebc4346/src/librustdoc/clean/inline.rs#L215-L219

so we're going to want something similar, like let asyncness = tcx.fn_asyncness(...). Here I changed the query to return a hir::Asyncness type instead of a bool, but it's easy enough either way.

But first we need to add that is_async_fn query. We can look at is_min_const_fn as a model, although it has a few complications. In particular, is_min_const_fn turns out to be a regular tcx method that invokes the is_const_fn_raw helper (and then does some other stuff). We're more interested in the is_const_fn_raw model, since we don't need that other stuff.

is_const_fn_raw is defined in the query/mod.rs file:

https://github.com/rust-lang/rust/blob/3287a65fc05028dce3b521765f4643384ebc4346/src/librustc/query/mod.rs#L237-L245

The "provider" (function that gets called) for local functions is given in ty/constness.rs:

https://github.com/rust-lang/rust/blob/3287a65fc05028dce3b521765f4643384ebc4346/src/librustc/ty/constness.rs#L71-L84

and installed into the provider struct down below:

https://github.com/rust-lang/rust/blob/3287a65fc05028dce3b521765f4643384ebc4346/src/librustc/ty/constness.rs#L110-L115

The tricky part comes when the function is loaded from metadata from another crate. That requires us to edit the librustc_metadata modules. The first step would be to extend the schema:

https://github.com/rust-lang/rust/blob/3287a65fc05028dce3b521765f4643384ebc4346/src/librustc_metadata/schema.rs#L296-L301

Here, we would add a field like asyncness: hir::Asyncness. Then we'll have to modify the encoder to provide a value for that field, e.g. here:

https://github.com/rust-lang/rust/blob/3287a65fc05028dce3b521765f4643384ebc4346/src/librustc_metadata/encoder.rs#L887-L891

Here we would just read it from the HIR. Finally, we have to modify the decoder and "crate store impl" files so that when you invoke the fn_asyncness query on an external crate, it gets routed the right way. For that we would add a function like is_const_fn_raw to decoder.rs:

https://github.com/rust-lang/rust/blob/3287a65fc05028dce3b521765f4643384ebc4346/src/librustc_metadata/decoder.rs#L1201-L1209

and then add an entry to the macro which invokes this function when the query is called, kind of like this:

https://github.com/rust-lang/rust/blob/3287a65fc05028dce3b521765f4643384ebc4346/src/librustc_metadata/cstore_impl.rs#L135

This macro basically says "when this tcx query is called on something from a foreign crate, invoke this method on the cdata variable ('crate data')".

[hirschenberger]

Oh, seems I was too late :disappointed:

@nikomatsakis But thanks for the tried mentoring