Add new LSP extension for workspace symbol lookup

[alcroito]

As well as all symbol types (functions, modules).

Remove outdated documentation regarding symbol lookup filtering.

Closes #4881

[alcroito]

The current PR makes the UX of using RA with VSCode a bit nicer (IMHO), but I realize it removes the filtering functionality from other editors.

If that's unacceptable, perhaps we could expose these filtering knobs as settings to be controlled in VSCode? Or detect VSCode as the LSP client and set them accordingly?

[matklad]

Yeah, it's sad that this got broken in vs code. That being said, I think searching in the current workspace by default works better, and I definitely think that we should keep the heuristic of "search for types by default, if there are no results, search for all symbols instead".

Let's make this user configurable. In config.rs, I think we should add:

search.dependencies: bool = false,
search.allSymbols: bool = false,

[petr-tik]

Let's make this user configurable. In config.rs, I think we should add:

search.dependencies: bool = false,
search.allSymbols: bool = false,

Would it be possible to override these settings on per-request basis? i.e. starting ra with default to not search dependencies, but changing it for 1 request, when you might want to see them.

I think this is the perfect usecase for an elisp function that takes an optional prefix argument similar to this function in lsp-clangd. That way, we can call M-x lsp-find-workspace-symbol or C-u M-x lsp-find-workspace-symbol to include dependencies in the results.

[matklad]

@petr-tik emacs can directly add * and # to the query string, this PR is specifically for VS Code.

That being said, given that #* workaround is broken in vscode, it make sense to design a proper LSP extension here. See the how-to for how this should be done: https://github.com/rust-analyzer/rust-analyzer/tree/master/docs/dev#how-to-

basically, we need to add two fields to lsp request params: search_scope and search_kinds

[alcroito]

Pushed code to implement a new LSP extension extending the usual workspace symbol lookup request.

Aside from bikeshedding names (suggestions welcomes), I'd like some feedback for a few open points:

1. I added the additional search_scope and search_kind params to both the global server config, as well as to the request. Is that desirable?
2. I assume we want a search_kind enum instead of an OR'ed flag-like search_kinds to keep it simple?
3. Currently the logic still checks for the * and # markers because there might be existing LSP clients using that. Do we want it? Current precedence logic is markers (most important) -> request params -> global config
4. config.rs currently transforms WorskpaceSymbolSearchScopeDef into lsp_ext::WorkspaceSymbolSearchScope. I'm not sure if we want an additional enum / struct indirection in between those.
5. I haven't actually tested the per-request params case, only the VSCode setting -> rust-analyzer global config path. Is there an easy way to check the per-request case?

Of course let me know if i did something incorrectly.

[flodiebold]

Since the markers work fine in Emacs, I would vote for keeping them.

[kjeremy]

Should we file an issue or proposal on https://github.com/microsoft/language-server-protocol?

[matklad]

Ouch, sorry @alcroito, this fell of my radar. Feel free to tag @matklad if the PR is not reviewed.

The PR looks good to me as is (so, you picked the right answers for your questions!), we'd only want to expand the extension docs to actually specify the accepted format.

Is there an easy way to check the per-request case?

I don't think so, it's probably best to wait until Emacs some editor implements support for this.

[alcroito]

Updated PR.

Should I add some caveat / note to https://rust-analyzer.github.io/manual.html#workspace-symbol that the # and * markers don't work with VSCode?

[matklad]

Updating manual would be helpful, yeah (it’s in this repo)

…

On Tuesday, 18 May 2021, alcroito ***@***.***> wrote: Updated PR. Should I add some caveat / note to https://rust-analyzer.github. io/manual.html#workspace-symbol that that the # and '*' markers don't work with VSCode? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7698 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANB3M3YL3X2YXYHWBL3HVLTOGG67ANCNFSM4XW5SNKQ> .

[alcroito]

Updated manual to mention VSCode users shouldn't use the filtering symbols, but should rely on the config settings instead.

[matklad]

bors r+

Thanks!

[bors]

Timed out.

[lnicola]

bors retry

[bors]

Timed out.

[lnicola]

bors retry

[bors]

Build succeeded:

• Rust (macos-latest)
• Rust (ubuntu-latest)
• Rust (windows-latest)
• TypeScript (ubuntu-latest)
• TypeScript (windows-latest)