Get rid of doc(primitive)

[jyn514]

I was chatting with @compiler-errors on twitter about #87073. In retrospect I think the whole thing was overcomplicated and we can get the equivalent behavior much more simply by treating documentation on the re-exports in core::primitive as docs for the primitive items themselves, just like for normal re-exports.

This does mean we have to do something like

pub use core::primitive::usize;
pub use core::primitive::isize;
// ...

in std::primitive rather than just use core::primitive::*;. But that seems pretty simple compared to all the current special casing.

The last thing to deal with here is overwriting the docs instead of appending - I think that would need a new nightly rustdoc feature, but it would be pretty simple to implement, basically just an if condition in try_inline for this line:

rust/src/librustdoc/clean/inline.rs

Line 304 in 3b98c08

both.extend_from_slice(old_attrs);

So, an overview of all that:

1. Treat docs on re-exports of primitives as docs for the primitive themselves. This should probably be behind a feature gate.
2. Add a way to overwrite docs instead of appending in rustdoc, rather than special casing primitives only. This is probably useful just on its own, but should still be feature gated at first.
3. Remove all the mod bool hackery in std and rustdoc; add docs to the re-exports in core::primitive.

@rust-lang/rustdoc I don't plan to work on this, but does it make sense / sound like a good idea?

[GuillaumeGomez]

I think this would simplify things a lot. I didn't think it's a great idea and I'm all for it!

[GuillaumeGomez]

Just one thing I wonder: will this documentation remain available in core too? I think we can reexport primitives in core for their documentation to be displayed but better be sure.

[jyn514]

Yes, they're already there: https://doc.rust-lang.org/stable/core/primitive/index.html

[GuillaumeGomez]

Perfect! Then there is really nothing preventing us from doing it.

[Stupremee]

How would you handle primitives that aren't re-exported from core::primitive, like fn, slice, etc.?

[jyn514]

Oh, that's a good point :( maybe this wouldn't work

[jyn514]

going to close this, don't have ideas on how to make non-path primitives work :(