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.
9692: Use same cancelled spelling in doc and code. r=matklad a=mattiasgronlund
Right thing might be to update the spelling in the code to
follow American instead of English spelling, that is
using only canceled. But they should at least be aligned.
Right thing might be to update the spelling in the code to
follow American instead of English spelling, that is
using only canceled. But they should at least be aligned.
9688: feat: Resolve derive attribute input macro paths in ide layer r=Veykril a=Veykril
Enables goto def, syntax highlighting and hover for `Foo` in `#[derive(Foo)]`.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/4413
bors r+
This checks if a private item's location is editable (local source root), and completes them anyways if that's the case.
In order to test this, the `new_source_root` fixture command has been changed to take a `local` or `library` value, and to apply to all *following* files instead of the preceding ones (which would be hard to understand).
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9681: Respect `#[doc(hidden)]` in dot-completion r=jonas-schievink a=jonas-schievink
This adds `CompletionContext::is_visible` as a convenience method that checks visibility, presence of `doc(hidden)`, and whether the completed item is in the same crate as the completion site or not. We only complete `doc(hidden)` items from the same crate.
This doesn't yet work for *all* completions: `qualified_path` completions use `Module::scope` and `ScopeDef`, which doesn't work with this.
Part of https://github.com/rust-analyzer/rust-analyzer/issues/7718
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9678: Add Configuration for Highlight Related Feature r=kdelorey a=kdelorey
# Summary
Adds basic configuration that allows you to control when the highlight related feature is activated. You can control this for references, break points, exit points, and yield points.
9634: minor update to excludeDirs doc r=lnicola a=dae
I saw reference to globs in #7755, but it doesn't look like they're
actually supported, and I had to dig through the source to discover
that the folders are relative to the workspace root. Further digging
was required to get VS Code from hanging for long periods trying to
watch giant Bazel folders that had already been excluded from Rust
Analyzer. Hopefully this tweak will save others the confusion :-)
This introduces a new `Limits` structure which is passed as an input
to `SourceDatabase`. This makes limits accessible almost everywhere in
the code, since most places have a database in scope.
One downside of this approach is that whenever you query limits, you
essentially do an `Arc::clone` which is less than ideal.
Let me know if I missed anything, or would like me to take a different approach!
Co-authored-by: Robert Bartlensky <bartlensky.robert@gmail.com>
9660: hide keyword suggestions in non trivial paths r=Veykril a=Freax13
This pr hides keyword suggestions in non trivial paths:
Previously rust analyzer suggested a lot of keywords even when completing non trivial paths:
This had 2 problems:
1. Suggesting a keyword in this position doesn't make sense.
2. There are a lot of keywords, so they make it a lot harder to find the things you're actually looking for (note the scrollbar and that `instructions`, `registers` and `structures` are not visible).
Our project model code is rather complicated -- the logic for lowering
from `cargo metadata` to `CrateGraph` is fiddly and special-case. So
far, we survived without testing this at all, but this increasingly
seems like a poor option.
So this PR introduces a simple tests just to detect the most obvious
failures. The idea here is that, although we rely on external processes
(cargo & rustc), we are actually using their stable interfaces, so we
might just mock out the outputs.
Long term, I would like to try to virtualize IO here, so as to do such
mocking in a more principled way, but lets start simple.
Should we forgo the mocking and just call `cargo metadata` directly
perhaps? Touch question -- I personally feel that fast, in-process tests
are more important in this case than any extra assurance we get from
running the real thing.
Super-long term, we would probably want to extend our heavy tests to
cover more use-cases, but we should figure a way to do that without
slowing the tests down for everyone.
Perhaps we need two-tiered bors system, where we pull from `master` into
`release` branch only when an additional set of tests passes?
projects / rust.git / log