Previously, annotations would only appear above the name of an item (function signature, struct declaration, etc).
Now, rust-analyzer can be configured to show annotations either above the name or above the whole item (including doc comments and attributes).
Make use of NoHash hashing for FileId and CrateId
Both of these are mere integers so there is nothing to hash here.
Ideally we would use this for `la_arena::Idx` too, but that doesn't work due to the orphan rule, and `la_arena` is unfortunately a public library so we can't really do much here... Unless we remove the trait restriction but I'd like not to
feat: Run test mod from anywhere in parent file
The "Run" feature of rust-analyzer is super useful, especially for running
individual tests or test-modules during development.
One common pattern in rust development is to develop tests in the same file as
production code, inside a module (usually called `test` or `tests`) marked with
`#[cfg(test)]`. Unforunately, this pattern is not well supported by r-a today,
as a test module won't show up as a runnable unless the cursor is inside it.
In my experience, it is quite common to want to run the tests associated with
some production code immediately after editing it, not only after editing the
tests themselves. As such it would be better if test modules were available
from the "Run" menu even when the cursor is outside the test module.
This change updates the filtration logic for runnables in
`handlers::handle_runnables` to special case `RunnableKind::TestMod`, making
test modules available regardless of the cursor location. Other `RunnableKind`s
are unnaffected.
Fixes#9589
The "Run" feature of rust-analyzer is super useful, especially for running
individual tests or test-modules during development.
One common pattern in rust development is to develop tests in the same file as
production code, inside a module (usually called `test` or `tests`) marked with
`#[cfg(test)]`. Unforunately, this pattern is not well supported by r-a today,
as a test module won't show up as a runnable unless the cursor is inside it.
In my experience, it is quite common to want to run the tests associated with
some production code immediately after editing it, not only after editing the
tests themselves. As such it would be better if test modules were available
from the "Run" menu even when the cursor is outside the test module.
This change updates the filtration logic for runnables in
`handlers::handle_runnables` to special case `RunnableKind::TestMod`, making
test modules available regardless of the cursor location. Other `RunnableKind`s
are unnaffected.
Fixes#9589
This PR will fix some typos detected by [typos].
There are also some other typos in the function names, variable names, and file
names, which I leave as they are. I'm more certain that typos in comments
should be fixed.
[typos]: https://github.com/crate-ci/typos
rust-analyzer's RUSTC_WRAPPER unconditionally succeeds `cargo check`
invocations tripping up build scripts using `cargo check` to probe for
successful compilations. To prevent this from happening the RUSTC_WRAPPER
now checks if it's run from a build script by looking for the
`CARGO_CFG_TARGET_ARCH` env var that cargo sets only when running build
scripts.
When r-a starts up, it starts switching the workspace before all vfs
events have been processed which causes us to switch workspace multiple
times until all vfs changes have been processed. This scales with the
size of the project and its dependencies. If workspace files from
dependencies as well as the sysroot get loaded, we shouldn't switch
the workspace as those have no impact on the project workspace.
feat: Only flycheck workspace that belongs to saved file
Supercedes https://github.com/rust-lang/rust-analyzer/pull/11038
There is still the problem that all the diagnostics are cleared, only clearing diagnostics of the relevant workspace isn't easily doable though I think, will have to dig into that
feat: Spawn a proc-macro-srv instance per workspace
cc https://github.com/rust-lang/rust-analyzer/issues/12855
The idea is to have each server be spawned with the appropriate toolchain, that way workspaces with differing toolchains shouldn't suffer from proc-macro abi mismatches.
Rationale: Merge commits will probably end up in
`rust-lang/rust-analyzer` when doing "rust=>ra" syncs anyway.
It could be changed to only check for merge commits in non-sync PRs,
but it's "probably not worth the hassle"
This adds an `in-rust-tree` feature that will be enabled when
rust-analyzer is built from `rust-lang/rust`. Due to the way
"git subtree" works, that test _will_ find merge commits and
fail, so we simply skip it.
Add simple support for completion item details
Supercedes https://github.com/rust-lang/rust-analyzer/pull/9891
This doesn't yet really implement anything new, it just adds the scaffolding for the protocol conversion
fix: make file watcher config a drop-down (and clarify the options)
Fixes https://github.com/rust-lang/rust-analyzer/issues/12794
Also renames "notify" to "server", since that's clearer ("notify" is still accepted for compatibility).
fix: Pass the build data to rustc_private crates
With this all proc-macros should resolve in rustc now when setting up the build script running command properly.
make `files.excludeDirs` work
There's a small issue because if all projects are excluded, this: 01d412f4d7/crates/rust-analyzer/src/main_loop.rs (L114) will be shown.
I thought about not showing it if `files.excludeDirs` is set, but that is not necessarily correct.
Fixes#7755
Only advertise this feature in the server capabilities when the client
supports SnippetTextEdit.
Close#11398.
Co-authored-by: unexge <unexge@gmail.com>
feat: hide type inlay hints for initializations of closures
This PR adds an option to hide the inlay hints for `let IDENT_PAT = CLOSURE_EXPR;`, which is a somewhat common coding pattern. Currently the inlay hints for the assigned variable and the closure expression itself are both displayed, making it rather repetitive.
In order to be consistent with closure return type hints, only closures with block bodies will be hid by this option.
Personally I'd feel comfortable making it always enabled (or at least when closure return type hints are enabled), but considering the precedent set in #10761, I introduced an off-by-default option for this.
changelog feature: option to hide type inlay hints for initializations of closures
Config revamp
Fixes https://github.com/rust-lang/rust-analyzer/issues/11790
Fixes https://github.com/rust-lang/rust-analyzer/issues/12115
This PR changes a lot of config names, and a few ones are being merged or split apart. The reason for this is that our configuration names currently are rather inconsistent and some where poorly chosen in regards to extensability. This PR plans to fix that.
We still allow the old config names by patching them to the new ones before deserializing to keep backwards compatability with other clients (the VSCode client will auto update the config) but ideally we will get rid of that layer in the future.
Here is a list of the changes:
These are simple renames `old_name | alias1 | alias2 ... -> new_name` (the vscode client will fix these up automagically):
```
assist_allowMergingIntoGlobImports -> imports_merge_glob
assist_exprFillDefault -> assist_expressionFillDefault
assist_importEnforceGranularity -> imports_granularity_enforce
assist_importGranularity | assist_importMergeBehavior | assist_importMergeBehaviour -> imports_granularity_group
assist_importGroup -> imports_group_enable
assist_importPrefix -> imports_prefix
cache_warmup -> primeCaches_enable
cargo_loadOutDirsFromCheck -> cargo_buildScripts_enable
cargo_runBuildScripts | cargo_runBuildScriptsCommand -> cargo_runBuildScripts_overrideCommand
cargo_useRustcWrapperForBuildScripts -> cargo_runBuildScripts_useRustcWrapper
completion_snippets -> completion_snippets_custom
diagnostics_enableExperimental -> diagnostics_experimental_enable
experimental_procAttrMacros -> procMacro_attributes_enable
highlighting_strings -> semanticHighlighting_strings_enable
highlightRelated_breakPoints -> semanticHighlighting_breakPoints_enable
highlightRelated_exitPoints -> semanticHighlighting_exitPoints_enable
highlightRelated_yieldPoints -> semanticHighlighting_yieldPoints_enable
highlightRelated_references -> semanticHighlighting_references_enable
hover_documentation -> hover_documentation_enable
hover_linksInHover | hoverActions_linksInHover -> hover_links_enable
hoverActions_debug -> hoverActions_debug_enable
hoverActions_enable -> hoverActions_enable_enable
hoverActions_gotoTypeDef -> hoverActions_gotoTypeDef_enable
hoverActions_implementations -> hoverActions_implementations_enable
hoverActions_references -> hoverActions_references_enable
hoverActions_run -> hoverActions_run_enable
inlayHints_chainingHints -> inlayHints_chainingHints_enable
inlayHints_closureReturnTypeHints -> inlayHints_closureReturnTypeHints_enable
inlayHints_hideNamedConstructorHints -> inlayHints_typeHints_hideNamedConstructorHints
inlayHints_parameterHints -> inlayHints_parameterHints_enable
inlayHints_reborrowHints -> inlayHints_reborrowHints_enable
inlayHints_typeHints -> inlayHints_typeHints_enable
lruCapacity -> lru_capacity
runnables_cargoExtraArgs -> runnables_extraArgs
runnables_overrideCargo -> runnables_command
rustcSource -> rustc_source
rustfmt_enableRangeFormatting -> rustfmt_rangeFormatting_enable
```
These are configs that have been merged or split apart, which have to be manually updated by the user:
```
callInfo_full -> signatureInfo_detail, signatureInfo_documentation_enable
cargo_allFeatures, cargo_features -> cargo_features
checkOnSave_allFeatures, checkOnSave_features -> checkOnSave_features
completion_addCallArgumentSnippets completion_addCallParenthesis -> completion_callable_snippets
```
feat: allow customizing the command for running build scripts
I have tested this locally and it fixed#9201 with some small changes on the compiler side with suggestions from https://github.com/rust-analyzer/rust-analyzer/issues/9201#issuecomment-1019554086.
I have also added an environment variable `IS_RA_BUILDSCRIPT_CHECK` for crates to detect that it is a check for buildscripts, and allows defaulting to bogus values for expected environment variables.
11883: fix(ide): move moudle directory when rename r=rainy-me a=rainy-me
fix: #10992
Added `FileSystemEdit::MoveDir` variant for move dirs. Original implemented as recursively move child mod files but had many issues like
1. left empty dir after rename file
2. only affect rust file
3. not performant
so changed to current version
Co-authored-by: rainy-me <github@yue.coffee>
10802: Allow clients to configure the global workspace search limit r=Veykril a=knutwalker
Playing around with [helix](https://helix-editor.com) I realized that the global worksapce symbol search works different compared to vs-code.
Helix requires all possible symbols in one query and does no subsequent refinement searched.
This PR adds a configuration option to override the default search limit with the default being the currently hardocded value.
Helix users can increment this limit for their instance with a config like
```toml
[[language]]
name = "rust"
language-server = { command = "rust-analyzer" }
[language.config]
workspace = { symbol = { search = { limit = 65536 }}}
```
Other editors are not affected by this change.
Co-authored-by: Paul Horn <dev@knutwalker.engineer>
11866: fix: Prevent underflow in range conversion r=Veykril a=skyfmmf
Previously, when line numbers of Rust spans were converted to LSP ranges, they could underflow resulting in very large line numbers. As an underflow is always wrong, prevent it and use 0 instead.
This was noticed when opening an empty file in `src/bin/` of a library crate. In this case rustc produces a span with `"line_start": 0, "line_end": 0` resulting in the underflow.
Co-authored-by: Felix Maurer <felix@felix-maurer.de>
Previously, when line numbers of Rust spans were converted to LSP
ranges, they could underflow resulting in very large line numbers. As
an underflow is always wrong, prevent it and use 0 instead.
11445: Upstream inlay hints r=lnicola a=lnicola
Closes https://github.com/rust-analyzer/rust-analyzer/issues/2797
Closes https://github.com/rust-analyzer/rust-analyzer/issues/3394 (since now resolve the hints for the range given only, not for the whole document. We don't actually resolve anything due to [hard requirement](https://github.com/rust-analyzer/rust-analyzer/pull/11445#issuecomment-1035227434) on label being immutable. Any further heavy actions could go to the `resolve` method that's now available via the official Code API for hints)
Based on `@SomeoneToIgnore's` branch, with a couple of updates:
- I squashed, more or less successfully, the commits on that branch
- downloading the `.d.ts` no longer works, but you can get it manually from https://raw.githubusercontent.com/microsoft/vscode/release/1.64/src/vscode-dts/vscode.proposed.inlayHints.d.ts
- you might need to pass `--enable-proposed-api matklad.rust-analyzer`
- if I'm reading the definition right, `InlayHintKind` needs to be serialized as a number, not string
- this doesn't work anyway -- the client-side gets the hints, but they don't display
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
11424: Pass required features to cargo when using run action r=Veykril a=WaffleLapkin
When using `F1`->`Rust Analyzer: Run` action on an `example`, pass its `required-features` to `cargo run`. This allows to run examples that were otherwise impossible to run with RA.
Co-authored-by: Maybe Waffle <waffle.lapkin@gmail.com>
When using `F1`->`Rust Analyzer: Run` action on an `example`, pass its
`required-features` to `cargo run`. This allows to run examples that
were otherwise impossible to run with RA.
11182: fix: don't panic on seeing an unexpected offset r=Veykril a=dimbleby
Intended as a fix, or at least a sticking plaster, for #11081.
I have arranged that [offset()](1ba9a924d7/crates/ide_db/src/line_index.rs (L105-L107)) returns `Option<TextSize>` instead of going out of bounds; other changes are the result of following the compiler after doing this.
Perhaps there's still an issue here - I suppose the server and client have gotten out of sync and that probably shouldn't happen in the first place? I see that https://github.com/rust-analyzer/rust-analyzer/issues/10138#issuecomment-913727554 suggests what sounds like a more substantial fix which I think might be aimed in this direction. So perhaps that one should be left open to cover such things?
Meanwhile, I hope that not-crashing is a good improvement: and I can confirm that it works out just fine in the repro I have at #11081.
Co-authored-by: David Hotham <david.hotham@metaswitch.com>
11281: ide: parallel prime caches r=jonas-schievink a=jhgg
cache priming goes brrrr... the successor to #10149
---
this PR implements a parallel cache priming strategy that uses a topological work queue to feed a pool of worker threads the crates to index in parallel.
## todo
- [x] should we keep the old prime caches?
- [x] we should use num_cpus to detect how many cpus to use to prime caches. should we also expose a config for # of worker CPU threads to use?
- [x] something is wonky with cancellation, need to figure it out before this can merge.
Co-authored-by: Jake Heinz <jh@discordapp.com>
11145: feat: add config to use reasonable default expression instead of todo! when filling missing fields r=Veykril a=bnjjj
Use `Default::default()` in struct fields when we ask to fill it instead of putting `todo!()` for every fields
before:
```rust
pub enum Other {
One,
Two,
}
pub struct Test {
text: String,
num: usize,
other: Other,
}
fn t_test() {
let test = Test {<|>};
}
```
after:
```rust
pub enum Other {
One,
Two,
}
pub struct Test {
text: String,
num: usize,
other: Other,
}
fn t_test() {
let test = Test {
text: String::new(),
num: 0,
other: todo!(),
};
}
```
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Coenen Benjamin <benjamin.coenen@hotmail.com>
The direct reason for this is to fix CI on windows, which seems to fail
for some reason after we fixed the watcher-selection logic which (I
think) changed the tests behavior to use notify rather than client.
But this patch seems to make sense in general -- file watching is
notoriously finicky, so controlling it explicitly leads to less fragile
tests.
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>
10649: internal: Remove `CompletionKind` in favor of `CompletionItemKind` r=Veykril a=Veykril
and move some more tests around
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10503: Only include targets of packages that are workspace members r=Veykril a=bcully
CargoWorkspace's package list includes packages that are path
dependencies, even if those packages aren't actually members of the
cargo workspace. As a result, rust-analyzer's runnable finder, which
returns the target from the first workspace that has a matching package,
may select the wrong working directory, causing runnables to fail, e.g.,
```
error: package `root` cannot be tested because it requires dev-dependencies and is not a member of the workspace
```
To fix this, we filter out packages that aren't members of the workspace
when searching for targets.
Fixes#7764
Co-authored-by: Brendan Cully <brendan@cully.org>
10423: Internal: refactor for mdbook plugin r=Veykril a=HKalbasi
This PR is for upstreaming changes that I made for mdbook plugin. Changes are adding inlay hints to `StaticIndex` and changing some functions for working around privacy of crates.
Aside this, is it okay if I bring the plugin in tree? It is a simple binary crate. I feel it will better maintained here and become resistant to api changes.
Co-authored-by: hamidreza kalbasi <hamidrezakalbasi@protonmail.com>
CargoWorkspace's package list includes packages that are path
dependencies, even if those packages aren't actually members of the
cargo workspace. As a result, rust-analyzer's runnable finder, which
returns the target from the first workspace that has a matching package,
may select the wrong working directory, causing runnables to fail, e.g.,
```
error: package `root` cannot be tested because it requires dev-dependencies and is not a member of the workspace
```
To fix this, we filter out packages that aren't members of the workspace
when searching for targets.
Fixes#7764
10522: fix: make signature info response conform to spec r=lnicola a=muscar
This addreses https://github.com/rust-analyzer/rust-analyzer/issues/10464.
This patch picks up `lsp-types` 0.90.1, which serialises the `SignatureInformation` and `ParameterInformation` with the right casing. It also adds `activeSignature` field as part of the top-level signature response. It keeps `activeParameter` at the top-level for backwards compatibility.
Co-authored-by: Alex Muscar <alex@muscar.eu>
This addreses
https://github.com/rust-analyzer/rust-analyzer/issues/10464.
This patch picks up `lsp-types` 0.90.1, which serialises the
`SignatureInformation` and `ParameterInformation` with the right casing.
It also adds `activeSignature` field as part of the top-level signature
response. It keeps `activeParameter` at the top-level for backwards
compatibility.
10181: Begining of lsif r=HKalbasi a=HKalbasi
This PR adds a `lsif` command to cli, which can be used as `rust-analyzer lsif /path/to/project > dump.lsif`. It now generates a valid, but pretty useless lsif (only supports folding ranges). The propose of this PR is to discussing about the structure of lsif generator, before starting anything serious.
cc `@matklad` #8696#3098
Co-authored-by: hamidreza kalbasi <hamidrezakalbasi@protonmail.com>
10105: RfC: Use `todo!()` instead of `()` for missing fields r=jonas-schievink a=jo-so
Most commonly a field of a struct can be initialized with its default value than an empty tuple.
Co-authored-by: Jörg Sommer <joerg@jo-so.de>
10332: minor: Allow overwriting RUST_BACKTRACE for the server manually r=jonas-schievink a=Veykril
Trying to figure out why we aren't getting backtraces for windows builds from CI, this let's one set the backtraces to `FULL`
Might be cc https://github.com/rust-lang/rust/issues/87481
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
With this patch, in these examples
```rust
fn main() {
"⊞$0";
}
```
```rust
struct S {
д$0 u8
}
```
entering ':' character in `$0` places shouldn't cause panics.
The generated code with `()` doesn't compile in most of the cases. To signal
the developer there's something to do, fill in `todo!()`.
Because the file *missing_fields.rs* contains the string `todo!()` it needs
an exception for the test *check_todo*.
When dealing with proc macros, there are two very different kinds of
errors:
* first, usual errors of "proc macro panicked on this particular input"
* second, the proc macro server might day if the user, eg, kills it
First kind of errors are expected and are a normal output, while the
second kind are genuine IO-errors.
For this reason, we use a curious nested result here: `Result<Result<T,
E1>, E2>` pattern, which is 100% inspired by http://sled.rs/errors.html
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).
10005: Extend `CargoConfig.unset_test_crates` r=matklad a=regexident
This is to allow for efficiently disabling `#[cfg(test)]` on all crates (by passing `unset_test_crates: UnsetTestCrates::All`) without having to first load the crate graph, when using rust-analyzer as a library.
(FYI: The change doesn't seem to be covered by any existing tests.)
Co-authored-by: Vincent Esche <regexident@gmail.com>
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.
I don't think there's anything wrong with project_model depending on
proc_macro_api directly -- fundamentally, both are about gluing our pure
data model to the messy outside world.
However, it's easy enough to avoid the dependency, so why not.
As an additional consideration, `proc_macro_api` now pulls in `base_db`.
project_model should definitely not depend on that!
cargo llvm-lines shows that path_to_error bloats the code. I don't think
I've needed this functionality recently, seems that we've fixed most of
the serialization problems. So let's just remove it. Should be easy to
add back if we ever need it, and it does make sense to keep the
`from_json` function around.
9830: Enable more assists to generate default trait body impls r=Veykril a=yoshuawuyts
Enable more assists to benefit from trait body generation. Follow-up to #9825 and #9814.
__edit:__ I'd like to move the existing tests to this new file too, but I'll do that in a follow-up PR.
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
From the dawn of time, when dinosaurs roamed the and we didn't have
hierarchical profiling, there was the `latest_requests` infra we used to
track the time of ten last requests.
Today, no one is actually using it and, what's more, it itself became
pretty useless -- LSP grew way more chatty, and 10 requests don't really
paint any kind of picture.
Personally, it's been years since I last looked at latest requests in
the status output.
So, let's remove a tiny bit of state from the big ball of complexity
that is `GlobalState` and `main_loop`!
We generally avoid "syntax only" helper wrappers, which don't do much:
they make code easier to write, but harder to read. They also make
investigations harder, as "find_usages" needs to be invoked both for the
wrapped and unwrapped APIs
9734: semantic highlighting: add reference hlmod r=matklad a=jhgg
This PR adds the "reference" highlight modifier!
I basically went around and looked for `HlMod::Mutable` to find the callsites to add a reference. I think these all make sense!
Co-authored-by: Jake Heinz <jh@discordapp.com>
Co-authored-by: Jake <jh@discordapp.com>
Some features of rust-analyzer requires support for custom commands on
the client side. Specifically, hover & code lens need this.
Stock LSP doesn't have a way for the server to know which client-side
commands are available. For that reason, we historically were just
sending the commands, not worrying whether the client supports then or
not.
That's not really great though, so in this PR we add infrastructure for
the client to explicitly opt-into custom commands, via `extensions`
field of the ClientCapabilities.
To preserve backwards compatability, if the client doesn't set the
field, we assume that it does support all custom commands. In the
future, we'll start treating that case as if the client doesn't support
commands.
So, if you maintain a rust-analyzer client and implement
`rust-analyzer/runSingle` and such, please also advertise this via a
capability.
9693: feat: Add the Hover Range capability which enables showing the type of an expression r=matklad a=alexfertel
Closes https://github.com/rust-analyzer/rust-analyzer/issues/389
This PR extends the `textDocument/hover` method to allow getting the type of an expression. It looks like this:
Edit: One thing I noticed is that when hovering a selection that includes a macro it doesn't work, so maybe this would need a follow-up issue discussing what problem that may have.
(PS: What a great project! I am learning a lot! 🚀)
Co-authored-by: Alexander Gonzalez <alexfertel97@gmail.com>
Co-authored-by: Alexander González <alexfertel97@gmail.com>
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>
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 :-)
Co-authored-by: Damien Elmes <gpg@ankiweb.net>
Co-authored-by: Damien Elmes <dae@users.noreply.github.com>
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 :-)
Note that, while we don't currently have a fuzzy-matching score, it
makes sense to special-case postfix templates -- it's very annoying when
`.not()` gets sorted before `.not`. We might want to move this infra to
fuzzy matching, once we have that!
Before this PR, SourceChange used a bool and CompletionItem used an enum
to signify if edit is a snippet. It makes sense to use the same pattern
in both cases. `bool` feels simpler, as there's only one consumer of
this API, and all producers are encapsulated anyway (we check the
capability at the production site).
One source completion can produce up to two lsp completions.
Additionally, `preselct` and `sort_text` are global properties of the
whole set of completions, so the right granularity here is to convert
many completions.
As a side-benefit, we no loger allocate intermediate vec.
Moving tests to `rust-analyzer` crate allows removing walkdir dependency
from `xtask`. It does seem more reasonable to keep tidy tests outside of
the "build system" and closer to other integration tests.
* Keep codegen adjacent to the relevant crates.
* Remove codgen deps from xtask, speeding-up from-source installation.
This regresses the release process a bit, as it now needs to run the
tests (and, by extension, compile the code).
9269: Recreate status page r=lnicola a=Milo123459
I'm working on redesigning the status page.
Co-authored-by: Milo <50248166+Milo123459@users.noreply.github.com>
9380: feat: Implement goto_declaration support r=matklad a=Veykril
This is just a simple implementation that falls back to `goto_definition` for everything but modules where it goes to the actual module declaration if possible.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9348: output to log file if RA_LOG_FILE is defined in environment r=rezural a=rezural
This adds a check for RA_LOG_FILE, and logs to that if defined. It currently overrides flags.log_file. If this is undesirable, I will add a check.
Co-authored-by: rezural <rezural@protonmail.com>
9264: feat: Make documentation on hover configurable r=Veykril a=Veykril
This also implements deprecation support for config options as this renames `hoverActions_linksInHover` to `hover_linksInHover`.
Fixes#9232
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9258: minor: Give `ImportPrefix` variants better config names r=matklad a=Veykril
I feel like `crate` and `self` work better than `by_crate` and `by_self`. The only reason for the current names were that `Self` doesn't work for the variant name on the rust side so I forgot about setting proper config names on serde layer.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9260: tree-wide: make rustdoc links spiky so they are clickable r=matklad a=lf-
Rustdoc was complaining about these while I was running with --document-private-items and I figure they should be fixed.
Co-authored-by: Jade <software@lfcode.ca>
8866: Update salsa r=matklad a=jonas-schievink
This updates salsa to include https://github.com/salsa-rs/salsa/pull/265, and removes all cancellation-related code from rust-analyzer
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
The current logic used to transfer global_excludes into vfs exclusions
only transfers global_excludes that are the parent of an item in
dirs.include.
This commit additionally adds an item from global_exclude to the vfs
exclusions if the global_exclude is a child of an included item.
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>
8942: Add `library` semantic token modifier to items from other crates r=arzg a=arzg
Closes#5772.
A lot of code here is pretty repetitive; please let me know if you have any ideas how to improve it, or whether it’s fine as-is.
Side-note: How can I add tests for this? I don’t see a way for the test Rust code in `test_highlighting` to reference other crates to observe the new behaviour.
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
8873: Implement import-granularity guessing r=matklad a=Veykril
This renames our `MergeBehavior` to `ImportGranularity` as rustfmt has it as the purpose of them are basically the same. `ImportGranularity::Preserve` currently has no specific purpose for us as we don't have an organize imports assist yet, so it currently acts the same as `ImportGranularity::Item`.
We now try to guess the import style on a per file basis and fall back to the user granularity setting if the file has no specific style yet or where it is ambiguous. This can be turned off by setting `import.enforceGranularity` to `true`.
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8870
Co-authored-by: Lukas Tobias Wirth <lukastw97@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.
8795: Allow semantic tokens for strings to be disabled r=matklad a=djrenren
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/7111
Pretty straightforward change, but open to any suggestions if there's a more recommended testing strategy than what I went with.
Co-authored-by: John Renner <john@jrenner.net>
