Prelude item shows up in two locations in docs

[bluss]

The items inside std::os::unix::prelude all get their own doc page under that namespace, which duplicates their more canonical location.

Compare:

• std::os::unix::process::CommandExt
• std::os::unix::prelude::CommandExt

This does not apply to std::io::prelude, I believe the difference is that the io prelude reexports items that are directly visible in their declared location.

Solving this (so that the prelude-ish module does not duplicate docs) would help me in third party library development as well.

[mitaa]

This does not apply to std::io::prelude, I believe the difference is that the io prelude reexports items that are directly visible in their declared location.

Yes, crate-local inlining inlines items that would be stripped at their original location and does not track whether, how often, or where an item has been inlined.

It'd be easy enough to apply doc(no_inline) (already attached to prelude::CommandExt) to crate-local inlining, which is currently only considered in cross-crate inlining.

The only issue is that rustdoc doesn't know about "canonical locations", so it's not quite clear what should be done about the (then probably broken) link of the prelude::CommandExt import.

[bluss]

So doc(no_inline) on those currently has no effect. Is the path that it uses to import the item not available?

[mitaa]

These links are generated using the fully resolved DefId, in this case pointing to std::sys::unix::ext::process::CommandExt, but apparently there is some redirect magic for public types in private modules (still broken for doc(hidden) though).

The used import-path is available as string-segments, but I'm a bit wary of using them to create links. (e.g. #29814)

[bluss]

Wow, you're so good at fixing rustdoc issues ❤️