In crates with prelude modules it often happens that searching for some item will yield multiple results, one for the actual item and one for its re-export in the prelude. This increases noise and makes it harder to find the actual definition of that item, in case you wanted to know its module and which other items are defined along with it. This gets even more noisy when the crate is split into multiple crates, each with its own prelude (see for example bevy, where each item is reported three times or more).
One possible solution for crate authors would be to mark the prelude as #[doc(hidden)], but this has the unfortunate downside that you won't be able to see the contents of the prelude in the documentation.
Would it be possible to tell rustdoc to hide either a specific item or all the items of a module from the search feature, while still producing documentation for them?
I think part of the issue is bevy has inline re-exports in its prelude, which basically tells rustdoc to treat them as separate types. Compare searching for std::FromIterator which uses non-inlined re-exports to searching for bevy::AppTypeRegistry:
(I'm not sure if the order of re-export last is explicit in the search logic, or just happens to be based on the type layout/naming)
Hmmm, that seems like a rustdoc bug about cross-crate re-exports of modules containing doc(hidden) items, which was supposedly fixed last year but I guess there's something about bevy's particular setup which didn't get fixed
As an aside, prelude re-exports are also a problem with IDE auto-importing; I'm not sure how rust-analyzer handles it, but RustRover seems to be somewhat inconsistent – sometimes it (unhelpfully) auto-imports the prelude path, and sometimes it asks which one should be imported. I haven't tested whether RustRover uses #[doc(hidden)] to decide whether a path is eligible for auto-import.
On the contray to my experience with RA on neovim, RA always imports non-prelude path, so I thought it would never know there is a prelude to use.
But after seeing the experience sharing, I did some experiments, and found the inconsistency too:
on an item needing to import, code action from RA will only help to import the publicly defining path, which is what I've always seen
as for the other hint to import from prelude, these E04* error code indicates rustc wants to help to import the prelude path, which I seems to never notice until now
