Setting `rust-analyzer.workspace.symbol.search.scope` to `workspace_and_dependencies` produces bad results

[thomaseizinger]

I am a VSCode user and I just learned about rust-analyzer.workspace.symbol.search.scope. Searching types from dependencies has been one of the features I really missed from IntelliJ.

Unfortunately, it appears that it is almost unusable in its current form. I am not sure what the sorting order is but it appears to be entirely random. I've also set rust-analyzer.workspace.symbol.search.scope to all_symbols and even when typing an exact symbol name from my local workspace, VSCode shows fuzzy-matched results from some my dependencies:

I think the results should be sorted by "distance" to the currently open file:

• Matches in the local workspace
• Matches in direct dependencies of the current crate
• Matches in direct dependencies of any workspace crate
• Matches in transitive dependencies

An MVP of the above could be to just prioritize workspace matches over dependency ones although I do think getting the order of results from dependencies right is also key.

A somewhat obvious one is also that full or at least partial matches should be prioritized over fuzzy-matched ones.

[asartamonov]

Great point actually.
But there is an issue with VSCode itself - it filters out special symbols * and # which could be used to narrow down results from 'dependencies' to 'local workspace' (see rust-analyzer manual https://rust-analyzer.github.io/manual.html#workspace-symbol).
I also see an issue with searching fuzzyness as although we have SearchMode::Exact along with SearchMode::Fuzzy, there is no way to switch it when searching symbols, it is SearchMode::Fuzzy by default and no user api to change it, as long as I see in src (https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide-db/src/symbol_index.rs#L48) no way to interact with 'exact(&mut self)' method for a user. SearchMode::Exact is default resolution strategy for imports only, not customisable also.

It would be great to have some .. special symbol (?) like ? or ! to customise fuzzyness behaviour?
?Foo* - fuzzy search Foo in dependencies
!Foo* - exact search Foo in dependencies
But again, what VSCode users can do with special symbols.

[Veykril]

Indeed, we can barely do anything with the feature as it stands right now, as VSCode has this implemented very weakly for the LSP protocol.

[thomaseizinger]

Great point actually.
But there is an issue with VSCode itself - it filters out special symbols * and # which could be used to narrow down results from 'dependencies' to 'local workspace'

i don't understand what special symbols have to do with narrowing down the search. I don't actually want any special symbols to tweak the search. Instead, results should be sorted such that the most relevant ones come first (for example, based on likelihood I listed above).

Some more notes on what IntelliJ does (which I think works really well):

• Using all upper case letters matches camel-case letters: If there exists a symbol FooBarBaz and I search for FBB, it should rank reasonably high because of: FooBarBaz
• Search for files vs symbols should be split. This already works by searching with # prefix vs not. This makes sense because those are two different namespaces of things I am searching for.
• Always fuzzy-match but prefer exact matches over non-exact ones

So, in summary I think we have a ranking problem here. The current search results are "correct" in that there is a (fuzzy) match. They are just not ranked in a useful order.

[jimmiebfulton]

I just spent three days working through this issue. I'm building an extension that allows for all project symbols to be discovered/listed, but I have the scope set to workspace_and_dependencies. Supplying a query helps narrow down results when looking for dependency symbols, but if project symbols are "drowned out", there is no way to effectively get all of the project symbols in the entire project, unless I run two rust-analyzers.