Suggested imports suggest dev-deps when re-exports are avail in regular dependency

[drahnr]

RA server suggest imports from [dev-dependencies] in non-test scopes. It also shadows alternative import paths of the same type via a different import path.

The sample code has instructions in crates/a/src/lib.rs.

rust-analyzer version: (eg. output of "rust-analyzer: Show RA Version" command, accessible in VSCode via Ctrl/⌘+Shift+P)
Doesn't seem to work 🤷 ``

rustc version: (eg. output of rustc -V)
rustc 1.88.0 (6b00bc388 2025-06-23)

editor or extension: (eg. VSCode, Vim, Emacs, etc. For VSCode users, specify your extension version; for users of other editors, provide the distribution if applicable)

Version: 1.96.4
Commit: cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba
Date: 2025-01-16T00:16:19.038Z
Electron: 32.2.6
ElectronBuildId: 10629634
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Linux x64 6.15.6-100.fc41.x86_64

Identical issue on zed:

Zed: v0.195.5 (Zed)
OS: Linux Wayland fedora 41
Memory: 30.1 GiB
Architecture: x86_64
GPU: AMD Radeon Graphics (RADV REMBRANDT) || radv || Mesa 25.0.7

relevant settings: (eg. client settings, or environment variables like CARGO, RUSTC, RUSTUP_HOME or CARGO_HOME) nothing specific

repository link (if public, optional): (eg. rust-analyzer)

MVE https://github.com/drahnr/bug-zed-rust-completion

code snippet to reproduce:

See above

[ChayimFriedman2]

I tried to work on this, but while it's easy to create some implementation, creating a robust implementation that will always tell whether some definition originates in a dev-dependency requires following the path it is used in which requires integration with name resolution, which I don't think is desirable.

[drahnr]

I think an intermediate step would be, to suggest all paths rather than just one path for a given type. That way I can at least manually pick the correct one.

The approach could then possibly be extended to start name resolution in the background and mark the types origin as dev dependency.

[ChayimFriedman2]

I think an intermediate step would be, to suggest all paths rather than just one path for a given type. That way I can at least manually pick the correct one.

That will create a lot of paths, I don't think this is a good idea.

The approach could then possibly be extended to start name resolution in the background and mark the types origin as dev dependency.

That's not easy, also my main motivation to resist changing name resolution is not performance but code mainatainability. Path finding is a pure IDE thing, I don't want nameres to be infected by it.

[drahnr]

That will create a lot of paths, I don't think this is a good idea.

Only if you allow all variants of super::super:: as well, not if you limit it to external crates.

[Veykril]

Items tend to be reachable from a multitude of paths (without containing super segments), our find path logic already considers a lot of these to figure out the "best" path. And in fact there are some crate setups (thanks to pervasive use of glob imports) that even managed to make r-a get stuck in the path finding computation because the reachability tree was just so vast.

Showing one path per extern crate in the dependency prelude of the current crate would probably be feasible though (in terms of UI overload), given that limits the number of paths to the number of direct dependencies.

[ChayimFriedman2]

@Veykril the problem is that it's not easy to determine the origin dependency.

If it's a direct dependency, sure, we can do that. But what if its a dependency of a dependency? Or maybe some other configuration?

[Veykril]

I was more referring to what the path is based on, that is (for fully qualified paths only), if our crate has 3 direct dependencies a, b and c. We at most show one path that begins with a, one with b, etc, if all those crates re-export the same item. That is the origin in this case is the extern crate the path starts out with. Naturally this does not work for relative paths.