Reexported intrinsics show up in rustdoc intra-doc links instead of their proper paths

[theemathas]

The following functions appear to be intrinsics that are re-exported at a different path (see also: #113387):

• intrinsics::transmute -> mem::transmute
• intrinsics::copy -> ptr::copy
• intrinsics::copy_nonoverlapping -> ptr::copy_nonoverlapping
• intrinsics::write_bytes -> ptr::write_bytes

Searching for these only finds the functions in std::intrinsics. (And for specifically transmute, it also shows core::mem::transmute for some reason.) The search result should ideally show the functions in std::mem/ptr. See below screenshots obtained by searching for transmute and searching for copy_nonoverlapping

[kpreid]

Possibly related: intra-doc links to std::mem::transmute or core::mem::transmute also end up linking to the intrinsic page.

[RalfJung]

Ouch, yes we should not push more people towards these accidentally-stable names. rustdoc should treat #[rustc_allowed_through_unstable_modules] functions in a pub module like pub fn in a private module.

Cc @rust-lang/rustdoc

[workingjubilee]

I wonder if we should just move the intrinsic defs to their reexport site and then reexport them from core::intrinsics.

[RalfJung]

If #135003 lands, we will start emitting a deprecation lint for std::intrinsics::transmute -- would be better if we didn't at the same time have rustdoc recommend exactly that deprecated path.

[theemathas]

Intra-doc links still link to the wrong place. For example, the link at https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html#method.from_raw points to the transmute intrinsic.

[RalfJung]

Hm yeah that is confusing -- it points to https://doc.rust-lang.org/nightly/std/intrinsics/fn.transmute.html which looks as if transmute itself is deprecated.

[RalfJung]

Note that the doc comment explicitly uses the std::mem path, and still rustdoc chooses the std::intrinsics path.

For private items that are re-exported publicly, rustdoc must have some logic that prints the public path rather than the private one. Could we make rustdoc consider the unstable path "private" and hence pretend it does not exist, therefore insisting on the proper stable path everywhere?