The reason for that was that we were calculating the crate defmaps
of the file we are saving by accident causing us to get stuck waiting
on their expensive computation, while we only need the relevant crate
id.
The main change here should be that flags are not inhereted, so
$ rust-analyzer analysis-stats . -v -v
would do what it should do
We also no longer Don\'t
This fixes a typo first appearing in #94624
in which test-macro diagnostic uses "a" article twice.
Since I searched sources for " a a " sequences,
I also fixed the same issue in a few source files where I found it.
Signed-off-by: Petr Portnov <gh@progrm-jarvis.ru>
Amalgamate file changes for the same file ids in process_changes
When receiving multiple change events for a single file id where the last change is a delete the server panics, as it tries to access the file contents of a deleted file. This occurs due to the VFS changes and the in memory file contents being updated immediately, while `process_changes` processes the events afterwards in sequence which no longer works as it will only observe the final file contents. By folding these events together, we will no longer try to process these intermediate changes, as they aren't relevant anyways.
Potentially fixes https://github.com/rust-lang/rust-analyzer/issues/13236
When receiving multiple change events for a single file id where the
last change is a delete the server panics, as it tries to access the
file contents of a deleted file. This occurs due to the VFS changes and
the in memory file contents being updated immediately, while
`process_changes` processes the events afterwards in sequence which no
longer works as it will only observe the final file contents. By
folding these events together, we will no longer try to process these
intermediate changes, as they aren't relevant anyways.
Potentially fixes https://github.com/rust-lang/rust-analyzer/issues/13236
proc-macro ABI breakage still affects the tests when a new stable version
releases. Ideally we'd still be able to run the tests on the rust-analyzer
repo without having to update the proc-macro ABI, but for now just to
unblock CI we will ignore them here, as they are still run in upstream.
Add a new configuration settings to set env vars when running cargo, rustc, etc. commands: cargo.extraEnv and checkOnSave.extraEnv
It can be extremely useful to be able to set environment variables when rust-analyzer is running various cargo or rustc commands (such as `cargo check`, `cargo --print cfg` or `cargo metadata`): users may want to set custom `RUSTFLAGS`, change `PATH` to use a custom toolchain or set a different `CARGO_HOME`.
There is the existing `server.extraEnv` setting that allows env vars to be set when the rust-analyzer server is launched, but using this as the recommended mechanism to also configure cargo/rust has some drawbacks:
- It convolutes configuring the rust-analyzer server with configuring cargo/rustc (one may want to change the `PATH` for cargo/rustc without affecting the rust-analyzer server).
- The name `server.extraEnv` doesn't indicate that cargo/rustc will be affected but renaming it to `cargo.extraEnv` doesn't indicate that the rust-analyzer server would be affected.
- To make the setting useful, it needs to be dynamically reloaded without requiring that the entire extension is reloaded. It might be possible to do this, but it would require the client communicating to the server what the overwritten env vars were at first launch, which isn't easy to do.
This change adds two new configuration settings: `cargo.extraEnv` and `checkOnSave.extraEnv` that can be used to change the environment for the rust-analyzer server after launch (thus affecting any process that rust-analyzer invokes) and the `cargo check` command respectively. `cargo.extraEnv` supports dynamic changes by keeping track of the pre-change values of environment variables, thus it can undo changes made previously before applying the new configuration (and then requesting a workspace reload).
Allow configuration of annotation location.
I've added the ability to configure where lens annotations render relevant to the item they describe. Previously, these would render directly above the line the item is declared on. Now, there is the ability to render these annotations above the entire item (including doc comments, and attributes).
The names of the config options are up for debate, I did what seemed best to me but if anyone has better ideas let me know.
This is my first contribution so if I've missed anything please let me know.
Here's a preview of what the new option looks like:
<img width="577" alt="Screen Shot 2022-09-11 at 10 39 51 PM" src="https://user-images.githubusercontent.com/33100798/189570298-b4fcbf9c-ee49-4b79-aae6-1037ae4f26af.png">
closes https://github.com/rust-lang/rust-analyzer/issues/13218
Restructure `find_path` into a separate functions for modules and non-module items
Follow up to https://github.com/rust-lang/rust-analyzer/pull/13212
Also renames `prefer_core` imports config to `prefer_no_std` and changes the behavior of no_std path searching by preferring `core` paths `over` alloc
This PR turned into a slight rewrite, so it unfortunately does a few more things that I initially planned to (including a bug fix for enum variant paths)
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.
