Prefer importing items from the crate they are defined in, rather than a re-export.

[JMS55]

libadwaita-rs depends on gtk-rs, which depends on glib-rs/gio-rs. The crates often re-export items from their dependencies, especially because of macros needing to use them. Yet, as a user, you will most likely be using items from all 4.

This leads to awkward issues where RA suggests importing "gio::prelude::item" instead of "glib::prelude::item" for an item originally defined in glib, and you end up with a really confusing mess of imports unless you figure out their paths manually.

I think that gtk-rs can improve their module organization to limit this to some degree, but it would maybe help to have RA prioritize importing items from the crate they were originally defined in.

As a related issue, often "item" will only have the import suggestion "gio::prelude::item", despite being also being available in "glib::submodule::item" or something similar. Not sure why that is.

[Veykril]

As a related issue, often "item" will only have the import suggestion "gio::prelude::item", despite being defined in "glib::submodule::item" or something similar. Not sure why that is.

r-a tries to use the shortest imports it can find, hence why it prefers the prelude there, regarding preludes there is not much we can do yet (we need to have some mechanism for libraries marking their preludes).

Regarding the overall issue, ye we should be able to do that just fine.

[jonas-schievink]

The crates often re-export items from their dependencies, especially because of macros needing to use them

For macros, it is common to put all items they need to access in a dedicated module and mark that module as #[doc(hidden)]. This will make r-a ignore the contained items during completion.

[flodiebold]

Do we take doc(hidden) into account for import completions? I didn't see anything related to that in find_path 🤔

[jonas-schievink]

Hmm, yeah, looks like we don't. That's definitely a bug.

[winterqt]

I see this with reqwest::Url and url::Url (the former being a reexport of the latter). They're both the same length, maybe both could be suggested instead of the first one?

[kianenigma]

Do we take doc(hidden) into account for import completions? I didn't see anything related

Seems like the right solution for this, and as far as I can see it is not implemented yet.

If anything is marked as doc(hidden) it should not be suggested. Otherwise, the shortest possible item makes sense.

[JelteF]

With the latest beta release of derive_more, rust-analyzer is now importing traits from derive_more instead of std: JelteF/derive_more#351

[JelteF]

What would be needed to hide doc(hidden) reexports? It seems like that should be a fairly easy filter.

[TheLostLambda]

From a super super cursory poke around (so this could be unusable), it looks like there is some functionality already for picking up on #[doc(hidden)]

rust-analyzer/crates/hir-def/src/attr.rs

Line 163 in e31c9f3

pub fn has_doc_hidden(&self) -> bool {

We'd just need to see if that's available information when picking the best path?

rust-analyzer/crates/hir-def/src/find_path.rs

Line 439 in e31c9f3

fn select_best_path(

[stepantubanov]

When trying to use Future, r-a always suggests futures::Future instead of std::future::Future, this may be the same issue?