fix: Correct references from `rust-analyzer.cargo.check` to `rust-analyzer.check`
When reading the manual, I noticed that the documentation referenced configurations that have since been renamed. This PR updates those references to their new names.
minor: Allow multiple snippet edits in a `TextDocumentEdit`
Explicitly[^1] allow a single `TextDocumentEdit` to have multiple `SnippetTextEdit`s. This allows things like renaming extracted variables and functions without having to go through a separate rename step. For an example of what this looks like, see the video in [this comment](https://github.com/microsoft/vscode/issues/145374#issuecomment-1177341711).
The behavior described here lines up with [what VSCode does](bdc113ffe1/src/vscode-dts/vscode.d.ts (L3728-L3731)), and presumably what the eventual LSP behavior will be.
[^1]: This was technically the case before #15269, a single `TextDocumentEdit` always had multiple edits which were `InsertTextFormat.Snippet` as all of the edits were marked as being snippets, even if there weren't any tab stops or placeholders.
Adds a Rust Analyzer configuration option to set a custom
target directory for builds. This is a workaround for Rust Analyzer
blocking debug builds while running `cargo check`. This change
should close#6007
extend check.overrideCommand and buildScripts.overrideCommand docs
Extend check.overrideCommand and buildScripts.overrideCommand docs regarding invocation strategy and location.
However something still seems a bit odd -- the docs for `invocationStrategy`/`invocationLocation` talk about "workspaces", but the setting that controls which workspaces are considered is called `linkedProjects`. Is a project the same as a workspace here or is there some subtle difference?
internal: Add config to specifiy lru capacities for all queries
Might help figuring out what queries should be limited by LRU by default, as currently we only limit `parse`, `parse_macro_expansion` and `macro_expand`.
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.
feat: Add clippy configuration section to the manual and update some old keys
Closes#14132
I don't think this is supposed to be under `Diagnostics`, but it does make sense in a way 🤷 (it's probably where someone might look).
Emacs has now two LSP clients, the more minimalistic and lightweight Eglot and
the extensive though a bit bloated LSP-Mode. Eglot will soon be
shipped with Emacs29. Both have rust-analyzer enabled by default and require
no further setup then just being installed and enabled. `lsp-rust.el` is not
required anymore.
The base-installation for each of those modes is so easy now that I don't think
an enumerated list is necessary, both package can be installed via the standard
`M-x package-install` and the installation is a one-liner that I provide.
Configuration mostly comes into play for support the rust-analyzer extensions to
the LSP protocol, which are built into LSP mode and require an extension-package
for Eglot.
But for the configuration beyond the base configuration I link against official
documentation, quickstart guides and documentation for the lsp extensions, to
avoid showing outdated information here.
This commit is mostly a duplicate of a PR [1] that I made against the
rust-analyzer github project.
[1]: https://github.com/rust-analyzer/rust-analyzer.github.io/pull/197,
7ff0113006
Spelling: Space before version number in Emacs 29 in manual
Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
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.
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
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? )
fix) update broken links in guide.md
Hi, I Just fixed some broken links in `guide.md`.
In most cases, it is not connected by an old version (expecially `guide-2019-01`) of the link, so I made some modifications.
Thanks for your time :)
`rustup` can now install `rust-analyzer` for the stable tool-chain. This commit removes the note that `rustup` can only install for the nightly branch and adjusts the command.
I also added a note on how to find the path to the `rust-analyzer` binary when installed using `rustup`, and suggestions on how to work around it not being placed in `~/.cargo/bin`.
I thought it would be ideal to point everyone to use `rustup run stable rust-analyzer` to start `rust-analyzer`. That would make it trivial to switch to nightly however I could not get this to work in `nvim` therefore I left it as a suggestion at the end.
