Beginning of MIR
This pull request introduces the initial implementation of MIR lowering and interpreting in Rust Analyzer.
The implementation of MIR has potential to bring several benefits:
- Executing a unit test without compiling it: This is my main goal. It can be useful for quickly testing code changes and print-debugging unit tests without the need for a full compilation (ideally in almost zero time, similar to languages like python and js). There is a probability that it goes nowhere, it might become slower than rustc, or it might need some unreasonable amount of memory, or we may fail to support a common pattern/function that make it unusable for most of the codes.
- Constant evaluation: MIR allows for easier and more correct constant evaluation, on par with rustc. If r-a wants to fully support the type system, it needs full const eval, which means arbitrary code execution, which needs MIR or something similar.
- Supporting more diagnostics: MIR can be used to detect errors, most famously borrow checker and lifetime errors, but also mutability errors and uninitialized variables, which can be difficult/impossible to detect in HIR.
- Lowering closures: With MIR we can find out closure capture modes, which is useful in detecting if a closure implements the `FnMut` or `Fn` traits, and calculating its size and data layout.
But the current PR implements no diagnostics and doesn't support closures. About const eval, I removed the old const eval code and it now uses the mir interpreter. Everything that is supported in stable rustc is either implemented or is super easy to implement. About interpreting unit tests, I added an experimental config, disabled by default, that shows a `pass` or `fail` on hover of unit tests (ideally it should be a button similar to `Run test` button, but I didn't figured out how to add them). Currently, no real world test works, due to missing features including closures, heap allocation, `dyn Trait` and ... so at this point it is only useful for me selecting what to implement next.
The implementation of MIR is based on the design of rustc, the data structures are almost copy paste (so it should be easy to migrate it to a possible future stable-mir), but the lowering and interpreting code is from me.
add openDocs command to context menu in VS Code extension
This adds the `openDocs` command to the VS Code context menu. I believe there are probably many user who are unaware of this command existing in the rust analyzer extension, and that this should enhance the discoverability of the command. Additionally, even if people are aware of this capability, it's helpful to have this in the context menu anyway; for example, one might forget the name of the command, or the keybinding they have assigned to it. I think that opening docs is a common enough action to warrant the extra line added to the context menu.
This makes a few other small changes as well. There are two minor style changes to increase style consistency. First, it changes the titles of the two commands that the rust analyzer extension will contribute to the context menu to title case. All standard VS Code commands that appear in the context menu are in title case. Second, it shortens the title of the `openDocs` command from `Open docs under cursor` to `Open Docs`. The implicit assumption in the standard VS Code context menu command titles is that the action applies to the symbol under the cursor: `Go to Definition`, `Find All References`, etc. Note that since these are changes to the command titles, rather than the command names themselves, these changes will not break any users' existing keybindings for these commands.
Second, this adds further restrictions to the `where` clauses of the two commands that the rust analyzer extension will contribute to the context menu, so that the two commands will appear in the context menu only when in a Rust project **and** within a Rust file. Say you have a Python or bash script inside your Rust project. Having these commands appear in the context menu when you right click a symbol in such a non-Rust file is extraneous and potentially confusing.
minor: Explicitly disable the rust-analyzer extension in untrusted workspaces
This is the default, but its always better to be explicit here + we can add a small note as to why.
Use ANSI control characters to display text decorations matching the
VScode terminal theme, and strip them out when providing text content
for rustc diagnostics.
This adds the small `anser` library to parse the control codes, and it
also supports HTML output so it should be fairly easy to switch to a
rendered HTML/webview implementation if desired.
Rename `checkOnSave` settings to `check`
Now that flychecks can be triggered without saving the setting name doesn't make that much sense anymore. This PR renames it to just `check`, but keeps `checkOnSave` as the enabling setting.
feat: add the ability to limit the number of threads launched by `main_loop`
## Motivation
`main_loop` defaults to launch as many threads as cpus in one machine. When developing on multi-core remote servers on multiple projects, this will lead to thousands of idle threads being created. This is very annoying when one wants check whether his program under developing is running correctly via `htop`.
<img width="756" alt="image" src="https://user-images.githubusercontent.com/41831480/206656419-fa3f0dd2-e554-4f36-be1b-29d54739930c.png">
## Contribution
This patch introduce the configuration option `rust-analyzer.numThreads` to set the desired thread number used by the main thread pool.
This should have no effects on the performance as not all threads are actually used.
<img width="1325" alt="image" src="https://user-images.githubusercontent.com/41831480/206656834-fe625c4c-b993-4771-8a82-7427c297fd41.png">
## Demonstration
The following is a snippet of `lunarvim` configuration using my own build.
```lua
vim.list_extend(lvim.lsp.automatic_configuration.skipped_servers, { "rust_analyzer" })
require("lvim.lsp.manager").setup("rust_analyzer", {
cmd = { "env", "RA_LOG=debug", "RA_LOG_FILE=/tmp/ra-test.log",
"/home/jlhu/Projects/rust-analyzer/target/debug/rust-analyzer",
},
init_options = {
numThreads = 4,
},
settings = {
cachePriming = {
numThreads = 8,
},
},
})
```
## Limitations
The `numThreads` can only be modified via `initializationOptions` in early initialisation because everything has to wait until the thread pool starts including the dynamic settings modification support.
The `numThreads` also does not reflect the end results of how many threads is actually created, because I have not yet tracked down everything that spawns threads.
Use diagnostic code as link to full message
fixes#13823 by adding a vscode setting that will keeping the existing diagnostic code and use it as a link to the full compiler error message.
While I was there I also fixed `index` to fallback to `rendered.length` to make the previewRustcOutput feature work.
feat: Add an option to hide adjustment hints outside of `unsafe` blocks and functions
As the title suggests: this PR adds an option (namely `rust-analyzer.inlayHints.expressionAdjustmentHints.hideOutsideUnsafe`) that allows to hide adjustment hints outside of `unsafe` blocks and functions:
Requested by `@BoxyUwU` <3
Support multiple targets for checkOnSave (in conjunction with cargo 1.64.0+)
This PR adds support for the ability to pass multiple `--target` flags when using
`cargo` 1.64.0+.
## Questions
I needed to change the type of two configurations options, but I did not plurialize the names to
avoid too much churn, should I ?
## Zulip thread
https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Issue.2013282.20.28supporting.20multiple.20targets.20with.201.2E64.2B.29
## Example
To see it working, on a macOS machine:
```sh
$ cd /tmp
$ cargo new cargo-multiple-targets-support-ra-test
$ cd !$
$ mkdir .cargo
$ echo '
[build]
target = [
"aarch64-apple-darwin",
"x86_64-apple-darwin",
]
' > .cargo/config.toml
$ echo '
fn main() {
#[cfg(all(target_arch = "aarch64", target_os = "macos"))]
{
let a = std::fs::read_to_string("/tmp/test-read");
}
#[cfg(all(target_arch = "x86_64", target_os = "macos"))]
{
let a = std::fs::read_to_string("/tmp/test-read");
}
#[cfg(all(target_arch = "x86_64", target_os = "windows"))]
{
let a = std::fs::read_to_string("/tmp/test-read");
}
}
' > src/main.rs
# launch your favorite editor with the version of RA from this PR
#
# You should see warnings under the first two `let a = ...` but not the third
```
## Screen
Helps with #13282
feat: add config for inserting must_use in `generate_enum_as_method`
Should fix#13312
Didn't add a test because I was not sure on how to add test for a specific configuration option, tried to look for the usages for other `AssistConfig` variants but couldn't find any in `tests`. If there is a way to test this, do point me towards it.
I tried to extract the formatting string as a common `template_string` and only have if-else for that, but it didn't compile :(
Also it seems these tests are failing:
```
test config::tests::generate_config_documentation ... FAILED
test config::tests::generate_package_json_config ... FAILED
```
Can you also point me to how to correct these 😅 ( I guess there is some command to automatically generate these? )
Implement invocation strategy config
Fixes https://github.com/rust-lang/rust-analyzer/issues/10793
This allows to change how we run build scripts (and `checkOnSave`), exposing two configs:
- `once`: run the specified command once in the project root (the working dir of the server)
- `per_workspace`: run the specified command per workspace in the corresponding workspace
This also applies to `checkOnSave` likewise, though `once_in_root` is useless there currently, due to https://github.com/rust-lang/cargo/issues/11007
VS Code problem matcher are restricted to be static "regexes". You can't
create a problem matcher dynamically, and you can't use custom code in
lieu of problem matcher.
This creates a problem for rust/cargo compiler errors. They use paths
relative to the root of the Cargo workspace, but VS Code doesn't
necessary know where that root is.
Luckily, there's a way out: our current problem matcher is defined like
this:
"fileLocation": [ "autoDetect", "${workspaceRoot}" ],
That means that relative pahts would be resoleved relative to workspace
root. VS Code allows to specify a command inside `${}`. So we can plug
custom logic there to fetch Cargo's workspace root!
And that's exactly what this PR is doing!
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
Remove the toggleInlayHints command from VSCode
Inlay hints are no longer something specifc to r-a as it has been upstreamed into the LSP, we don't have a reason to give the config for this feature special treatment in regards to toggling. There are plenty of other options out there in the VSCode marketplace to create toggle commands/hotkeys for configurations in general which I believe we should nudge people towards instead.
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).
Inlay hints are no longer something specifc to r-a as it has been
upstreamed into the LSP, we don't have a reason to give the config
for this feature special treatment in regards to toggling. There are
plenty of other options out there in the VSCode marketplace to create
toggle commands/hotkeys for configurations in general which I believe
we should nudge people towards instead.
[Prettier][1] is an up-to date code formatter for JavaScript ecosystem.
For settings we rely on [EditorConfig][2] for things like tab style and
size (with added bonus that the code editor with an EditorConfig plugin
does some automated code formatting on file save for you). Unfortunately,
Prettier's Glob handling isn't great:
1. `*.{ts,js,json}` has no effect
2. Similarly, in a list of globs `*.ts,*.js,*.json` only the first glob
has an effect, the rest are ignored.
That's why the file looks the way it does.
The only other setting we change is line width. [Lukas][3] suggested we
use 100 instead of 80, because that's what Rustfmt is using.
[1]: https://prettier.io
[2]: https://editorconfig.org
[3]: https://github.com/Veykril
feat: Support variable substitution in VSCode settings
Currently support a subset of [variables provided by VSCode](https://code.visualstudio.com/docs/editor/variables-reference) in `server.extraEnv` section of Rust-Analyzer settings:
* `workspaceFolder`
* `workspaceFolderBasename`
* `cwd`
* `execPath`
* `pathSeparator`
Also, this PR adds support for general environment variables resolution. You can declare environment variables and reference them from other variables like this:
```JSON
"rust-analyzer.server.extraEnv": {
"RUSTFLAGS": "-L${env:OPEN_XR_SDK_PATH}",
"OPEN_XR_SDK_PATH": "${workspaceFolder}\\..\\OpenXR-SDK\\build\\src\\loader\\Release"
},
```
The order of variable declaration doesn't matter, you can reference variables before defining them. If the variable is not present in `extraEnv` section, VSCode will search for them in your environment. Missing variables will be replaced with empty string. Circular references won't be resolved and will be passed to rust-analyzer server process as is.
Closes#9626, but doesn't address use cases where people want to use values provided by `rustc` or `cargo`, such as `${targetTriple}` proposal #11649
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.
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>
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>
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>
By changing the scope of this configuration to `machine-overridible`,
this setting becomes fully local for the VS Code instance the user is
running.
Having this setting excluded from syncing should help avoid
inconveniences for users who have VS Code installed on two different
operating systems, where the paths to the language server binary would
very likely mismatch.
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.
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 :-)
