Support DidChangeWorkspaceFolders notifications
This PR enables the `WorkspaceFoldersServerCapabilities` capability for rust-analyzer and implemented support for the associated [`DidChangeWorkspaceFolders`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_didChangeWorkspaceFolders) notification to allow clients to update the list of `workspaceFolders` sent during initialization.
## Motivation
This allows clients which lazily autodiscover their workspace roots (like the [helix editor](https://github.com/helix-editor/helix) once [my PR](https://github.com/helix-editor/helix/pull/5748) lands) avoid spawning multiple instances of RA. Right now such clients are forced to either:
* greedily discover all LSP roots in the workspace (precludes the ability to respond to new workspace roots)
* spawn multiple instance of rust-analyzer (one for each root)
* restart rust-analyzer whenever a new workspace is added
Some example use-cases are shown [here](https://github.com/helix-editor/helix/pull/5748#issuecomment-1421012523).
This PR will also improve support for VSCode (and Atom) multi workspaces.
## Implementation
The implementation was fairly straightforward as `rust-analyzer` already supports dynamically reloading workspaces, for example on configuration changes. Furthermore, rust-analyzer also already supports auto-discovering internal workspace from the `workspaceFolders` key in the initialization request. Therefore, the necessary logic just needed to be moved to a central place and reused.
Handle case when BlockExpr is child of IfExpr, WhileExpr, LoopExpr,
ForExpr.
An additional { } will be added when:
- It is not a BlockExpr
- It is a BlockExpr and a child of IfExpr, WhileExpr, LoopExpr, ForExpr.
Support sysroot library source being defined inside the workspace
With this you can now specify `cargo.sysrootSrc`. This is required for the rust workspace such that the `library` folder inside the workspace can be used as the sysroot library sources. We now also recognize if these sources are inside the workspace, tagging the as workspace members.
This does duplicate the sysroot crates still, but I don't think that causes too many problems.
Implement proc-macro-api versioning
So as it stands, we can't really change the proc-macro-api protocol at all without breaking all proc-macro servers again. To somewhat alleviate this we can move the supported ABI mess over to the proc-macro-api now by supporting multiple versions there (versions defined by us at least, not by rustc). Since the proc-macro-api protocol has no versioning scheme at the moment though, the best we can do here is add a new request to query the version from a server. Due to how the server currently works though, if it encounters an unknown request it will exit, meaning we can check if it is a server without support by checking if it exited after our version check request, that way we can support the current circulating server as well.
We need this since our span type will change from `TokenId` to something else at some point, but for that to work we need to comply with that the server expects. So knowing the version the server is using we can decide whether to send our new span data, or the tokenid (assuming we keep that information with our span data as well, alternatively we send irrelevant tokenids). That way we can keep old servers working while the user installations slowly migrate to newer servers that support the new spandata.
Support generic function in `generate_function` assist
Part of #3639
This PR adds support for generic function generation in `generate_function` assist. Now the assist looks for generic parameters and trait bounds in scope, filters out irrelevant ones, and generates new function with them.
See `fn_generic_params()` for the outline of the procedure, and see comments on `filter_unnecessary_bounds()` for criteria for filtering. I think it's good criteria for most cases, but I'm open to opinions and suggestions.
The diff is pretty big, but it should run in linear time w.r.t. the number of nodes we operate on and should be fast enough.
Some notes:
- When we generate function in an existing impl, generic parameters may cause name conflict. While we can detect the conflict and rename conflicting params, I didn't find it worthwhile mainly because it's really easy to resolve on IDE: use Rename functionality.
- I've implemented graph structure myself, because we don't have graph library as a dependency and we only need the simplest one.
- Although `petgraph` is in our dependency graph and I was initially looking to use it, we don't actually depend on it AFAICT since it's only used in chalk's specialization graph handling, which we don't use. I'd be happy to replace my implementation with `petgraph` if it's okay to use it though.
- There are some caveats that I consider out of scope of this PR. See FIXME notes on added tests.
feat: Remove support for 1.58 proc-macro abi
This seems old enough that we can drop the support for it now, the less ABIs we have the less work it is adjusting our span implementation.
Extracted from https://github.com/rust-lang/rust-analyzer/pull/14061, will rebase that over this once merged.
Don't escape non-snippets in assist
I was misunderstanding that we're always sending snippets as response to assist request. For assists that never return snippets like `move_const_to_impl` we don't need to escape, and I don't think `utils::escape_non_snippet()` is useful at the moment since we guarantee that only a single edit will have `InsertTextFormat.Snippet` and we have `utils::render_snippet()` for that.
internal: Remove hover fallback in favor of ranged hover
The fallback is usually more annoying than useful at this point (it messes with the range of diagnostic popups a lot), we now have a ranged hover to check the type of something which works a lot better.
Closes https://github.com/rust-lang/rust-analyzer/issues/11602
Don't respond with a ContentModified while loading the workspace
Initially this was done to prevent frequent inlay hint flickering, but this causes a lot of problems for a bunch of clients. We can (and already kind of have) move this into the semantic token request handlers instead.
Fixes https://github.com/rust-lang/rust-analyzer/issues/10910
Assist: desugar doc-comment
My need for this arose due to wanting to do feature dependent documentation and therefor convert parts of my doc-comments to attributes.
Not sure about the pub-making of the other handlers functions, but I didn't think it made much sense to reimplement them.
With #13552 the depencency of on the command-group crate was introduced, which also
introduced a dependency on nix. That version of nix does not build on Haiku. This
change introduces a newer version of command-group, which also updates nix from
0.22.3 to 0.26.1, which is compatible on Haiku.
