-
Notifications
You must be signed in to change notification settings - Fork 13.8k
Description
While examining API docs for ipfs_api_backend_hyper::IpfsClient
I was confused about the relationship between the symbol IpfsClient
and HyperBackend
:
I knew that rustdoc explicitly annotates type aliases, but that wasn't what I was seeing, so I fetched the code to examine and find a statement similar to use my_path::HyperBackend as IpfsClient
. Ok, but could rustdoc have helped me know this was happening?
I expected to see this happen:
I hope to see some explicit indication that the two symbols refer to the same item. The actual approach might be tricky to get right in a manner that is explicit but not too much clutter.
I've seen rustdoc explicitly annotate that when re-exporting across crate boundaries. Is there some way to do this for intra-crate renaming re-exports so that the crate-level doc would move IpfsClient
out of the structs section and into a re-exports section with a crate-local path? It currently looks like this:
With this proposed approach, the rendering for the type interface would consistently use HyperBackend
.
Related Tickets
I searched this issue tracker with is:issue is:open use as label:A-rustdoc-ui
to find these tickets both of which rename to _
which is distinct from my issue:
- Rustdoc doesn't play well with
use ... as _
syntax #97615 - Funky rustdoc behavior when
pub use path_to::Trait as _;
for public-in-private item #92379
I filed this PR against rust-ipfs-api which replaces use foo as bar
with explicit type aliases as a work-around. That PR has more screenshots of the difference in doc rendering between the two approaches.
Meta
rustc --version --verbose
:
Whatever https://docs.rs used to render https://docs.rs/ipfs-api-backend-hyper/0.6.0/ipfs_api_backend_hyper/index.html