2508: Code: don't check for ra_lsp_server on Windows r=matklad a=lnicola
Workaround for https://github.com/rust-analyzer/rust-analyzer/pull/2503#issuecomment-562980020.
~~(not yet tested on Windows)~~
We can't run `ra_lsp_server --version` right now because the server doesn't seem to handle arguments (so it hangs).
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
This commit implements a general truncation framework for HirFormatter
that keeps track of how much has been output so far. This information
can then be used to perform truncation inside the language server,
instead of relying on the client.
Initial support is implemented for truncating types hints using the
maxInlayHintLength server config option. The existing solution in the
VSCode extension has been removed in favor of letting the server
truncate type hints.
1984: Bump rollup and vsce r=matklad a=kjeremy
I got sick of the vsce warning on install and noticed that rollup was also out of date.
Co-authored-by: kjeremy <kjeremy@gmail.com>
The old `vscode` package is outdated and it is recommened to switch to
these two new packages. This also solves a problem of a missing `.d.ts`
for `vscode` in Nixos.
- only send request if workspace is initialized (emacs-lsp doesn't seem to
prevent sending requests before the initialized notification is sent)
- check whether we're still in the correct buffer before sending request
1652: Improve type hints behavior r=matklad a=SomeoneToIgnore
This PR fixed the following type hints issues:
* Restructures the `InlayKind` enum contents based on the discussion here: https://github.com/rust-analyzer/rust-analyzer/pull/1606#issuecomment-515968055
* Races described in #1639
* Caches the latest decorations received for each file to show them the next time the file is opened (instead of a new server request)
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
1458: Run VS Code tests on CI r=matklad a=etaoins
This is actually much faster than I expected; it takes about 13 seconds to download VS Code and run the unit tests. This means the VS Code tests are still significantly faster than the Rust ones.
If this ends up being unreliable we can always remove it later or move it to a separate optional job.
We also need to ignore the `.vscode-test` directory when running `prettier` or it will get upset about some temporary JSON files VS Code creates.
cc @killercup
Co-authored-by: Ryan Cumming <etaoins@gmail.com>
1459: Include primary span label in VS Code diagnostics r=matklad a=etaoins
In most cases the primary label span repeats information found elsewhere in the diagnostic. For example, with E0061:
```json
{
"message": "this function takes 2 parameters but 3 parameters were supplied",
"spans": [{"label": "expected 2 parameters"}]
}
```
However, with some mismatched type errors (E0308) the expected type only appears in the primary span's label, e.g.:
```json
{
"message": "mismatched types",
"spans": [{"label": "expected usize, found u32"}]
}
```
I initially added the primary span label to the message unconditionally. However, for most error types the child diagnostics repeat the primary span label with more detail. `rustc` also renders the duplicate text but because the span label and child diagnostics appear in visually distinct places it's not as confusing.
This takes a heuristic approach where it will only add the primary span label if there are no child message lines. For most error types the child messages repeat the primary span label with more detail.
Co-authored-by: Ryan Cumming <etaoins@gmail.com>
This adds `unreachable_code` to the list of diagnostic codes we map to
`Unnecessary` in Visual Studio Code. This is consistent with what the
TypeScript language server does.
In most cases the primary label span repeats information found elsewhere
in the diagnostic. For example, with E0061:
```
{
"message": "this function takes 2 parameters but 3 parameters were supplied",
"spans": [{"label": "expected 2 parameters"}]
}
```
However, with some mismatched type errors (E0308) the expected type only
appears in the primary span's label, e.g.:
```
{
"message": "mismatched types",
"spans": [{"label": "expected usize, found u32"}]
}
```
I initially added the primary span label to the message unconditionally.
However, for most error types the child diagnostics repeat the primary
span label with more detail. `rustc` also renders the duplicate text but
because the span label and child diagnostics appear in visually distinct
places it's not as confusing.
This takes a heuristic approach where it will only add the primary span
label if there are no child message lines.
This is actually much faster than I expected; it takes about 13 seconds
to download VS Code and run the unit tests. This means the VS Code tests
are still significantly faster than the Rust ones.
If this ends up being unreliable we can always remove it later or move
it to a separate optional job.
We also need to ignore the `.vscode-test` directory when running
`prettier` or it will get upset about some temporary JSON files VS Code
creates.
1454: Fix `cargo watch` code action filtering r=etaoins a=etaoins
There are two issues with the implementation of `provideCodeActions` introduced in #1439:
1. We're returning the code action based on the file its diagnostic is in; not the file the suggested fix is in. I'm not sure how often fixes are suggested cross-file but it's something we should handle.
2. We're not filtering code actions based on the passed range. The means if there is any suggestion in a file we'll show an action for every line of the file. I naively thought that VS Code would filter for us but that was wrong.
Unfortunately the VS Code `CodeAction` object is very complex - it can handle edits across multiple files, run commands, etc. This makes it complex to check them for equality or see if any of their edits intersects with a specified range.
To make it easier to work with suggestions this introduces a `SuggestedFix` model object and a `SuggestFixCollection` code action provider. This is a layer between the raw Rust JSON and VS Code's `CodeAction`s. I was reluctant to introduce another layer of abstraction here but my attempt to work directly with VS Code's model objects was worse.
Co-authored-by: Ryan Cumming <etaoins@gmail.com>
