4167: Filter out code actions if unsupported by the client and advertise our capabilities r=matklad a=kjeremy
This PR does three things:
1. If the client does not support `CodeActionKind` this will filter the results and only send `Command[]` back.
2. Correctly advertises to the client that the server supports `CodeActionKind`. This may cause clients to not request code actions if they are checking for the provider to be `true` (or implement LSP < 3.8) in the caps but I will fix that in a followup PR.
3. Marks most CodeActions as <strike>"refactor" so that they show up in the menu in vscode.</strike>`""`.
Part of #144#4147#2833
Co-authored-by: kjeremy <kjeremy@gmail.com>
4247: Fix pub(self) visibility? r=matklad a=DianaNites
Clippy complained about it and it seems wrong, copy paste error?
Co-authored-by: Diana <5275194+DianaNites@users.noreply.github.com>
4232: Update Roslyn link in syntax.md r=matklad a=osa1
Eric Lippert has a new blog that he keeps updating, update the link to that
Co-authored-by: Ömer Sinan Ağacan <omeragacan@gmail.com>
4153: Add support for incremental text synchronization r=matklad a=lnicola
Fixes#3762.
This still needs a `ra_vfs` PR, but I want to know I'm on the right track. I tested the change and it didn't crash horribly, but YMMV.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
4227: Report invalid, nested, multi-segment crate-paths r=matklad a=djrenren
There was a bug in the previous path-validating code that didn't detect multi-segment paths that started with `crate`.
```rust
// Successfully reported
use foo::{crate};
// BUG: was not being reported
use foo::{crate::bar};
```
This was due to my confusion about path-associativity. That is, the path with no qualifier is the innermost path, not the outermost. I've updated the code with a lot of comments to explain what's going on.
This bug was discovered when I found an erroneous `ok` test which I reported here:
https://github.com/rust-analyzer/rust-analyzer/issues/4226
This test now fails and has been modified, hopefully in the spirit of the original test, to be correct. Sorry about submitting the bug in the first place!
Co-authored-by: John Renner <john@jrenner.net>
4225: Special-case try macro_rules r=matklad a=edwin0cheng
Similar to #4221, but for `macro_rules! try {}`
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
4222: Introduce C/C++ for Visual Studio Code extension as an alternative debug engine for Debug Code lens. r=matklad a=vsrs
At the moment Debug Code Lens can use only one debug engine: lldb via [CodeLLDB](https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb) extension.
This PR adds support of the debug engine from the [MS C++ tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools) extension, as well as the configuration option. If both extensions are installed, `CodeLLDB` will be used by default.
Another new option `rust-analyzer.debug.sourceFileMap` allows, for example, to step into Rust std library during debugging. Works only with `MS C++ tools`.
On Windows:
```json
"rust-analyzer.debug.sourceFileMap": {
"/rustc/4fb7144ed159f94491249e86d5bbd033b5d60550": "${env:USERPROFILE}/.rustup/toolchains/stable-x86_64-pc-windows-msvc/lib/rustlib/src/rust"
}
```
On Linux:
```json
"rust-analyzer.debug.sourceFileMap": {
"/rustc/4fb7144ed159f94491249e86d5bbd033b5d60550": "~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust"
}
```
Co-authored-by: vsrs <vit@conrlab.com>
