10902: Handle multiple cargo check quick fix spans r=Veykril a=brandondong
Resolves https://github.com/rust-analyzer/rust-analyzer/issues/10705.
**Cause:**
- For a cargo check diagnostic with multiple spans, only a single quick fix action would be created at the location of `spans[0]`. Additionally, the hover window details would only show the location of `spans[0]` next to the message.
**Fix:**
- Allow cargo check quick fix actions to be triggerable from multiple selection ranges. Specifically, if the selection intersects with any of the replacement spans, the quick fix action is shown.
- No change in behavior for the hover window details. It's pretty minor and I think showing multiple locations next to the message may be more confusing anyways.
Co-authored-by: Brandon <brandondong604@hotmail.com>
closes#9922
Turned out to be trivial after preliminary refactor.
The intended behavior is that we schedule cache priming once ws become
quiescent (that is, we fully load cargo project), and we continue to
rschedule it until it completes (priming might get cancelled by user
typing into a file).
10080: internal: don't shut up the compiler when it says the code's buggy r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
It's good that rust-analyzer doesn't belly-up on a panic in some random
assist.
It is less good that rust-analyzer devs only know that the assists are
buggy when they are actively looking at the logs.
9558: Do not erase Cargo diagnostics from the closed documents r=matklad a=SomeoneToIgnore
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6850
The LSP specification at https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/#textDocument_publishDiagnostics states that
> Diagnostics notification are sent from the server to the client to signal results of validation runs.
>
> Diagnostics are “owned” by the server so it is the server’s responsibility to clear them if necessary. The following rule is used for VS Code servers that generate diagnostics:
>
> * if a language is single file only (for example HTML) then diagnostics are cleared by the server when the file is closed.
> * if a language has a project system (for example C#) diagnostics are not cleared when a file closes. When a project is opened all diagnostics for all files are recomputed (or read from a cache).
>
> When a file changes it is the server’s responsibility to re-compute diagnostics and push them to the client. If the computed set is empty it has to push the empty array to clear former diagnostics. Newly pushed diagnostics always replace previously pushed diagnostics. There is no merging that happens on the client side.
So for projects we should not clear any diagnostics from cargo/json projects.
Our "standalone file" mode is in a way a project too, with sysroot attached and a potential support for dynamic standalone files.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
8767: implement range formatting r=matklad a=euclio
Fixes#7580.
This PR implements the `textDocument/rangeFormatting` request using `rustfmt`'s `--file-lines` option.
Still needs some tests. What I want to know is how I should handle the instability of the `--file-lines` option. It's still unstable in rustfmt, so it's only available on nightly, and needs a special flag to enable. Is there a way for `rust-analyzer` to detect if it's using nightly rustfmt, or for users to opt-in?
Co-authored-by: Andy Russell <arussell123@gmail.com>
The new extension allows filtering of workspace symbool lookup
results by search scope or search kind.
Filtering can be configured in 3 different ways:
- The '#' or '*' markers can be added inline with the symbol lookup
query.
The '#' marker means symbols should be looked up in the current
workspace and any dependencies. If not specified, only current
workspace is considered.
The '*' marker means all kinds of symbols should be looked up
(types, functions, etc). If not specified, only type symbols are
returned.
- Each LSP request can take an optional search_scope or search_kind
argument query parameter.
- Finally there are 2 global config options that can be set for all
requests served by the active RA instance.
Add support for setting the global config options to the VSCode
extension.
The extension does not use the per-request way, but it's useful for
other IDEs.
The latest version of VSCode filters out the inline markers, so
currently the only reasonable way to use the new functionality is
via the global config.
