Commit graph

198 commits

Author SHA1 Message Date
Bastian Köcher
b58f84626f Switch to @types/vscode and vscode-test
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.
2019-08-26 08:22:48 +02:00
Aleksey Kladov
69bbe79c50 implement feature flags 2019-08-22 15:07:31 +03:00
Aleksey Kladov
6ab85cc192 fix default for the exlude key 2019-08-21 17:30:58 +03:00
xfoxfu
d07a85ed7e fix #1424
resolve "~" in raLspServerPath
2019-08-19 10:48:39 +08:00
Aleksey Kladov
13eddd7c49 Drop support for old extendSelection API
Emacs now handles this via native LSP request

dc86bbb227
2019-08-12 13:49:28 +03:00
Florian Diebold
e51c1d6bff Improvements to emacs inlay hints
- 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
2019-08-10 20:35:10 +02:00
bors[bot]
7e12422fa2 Merge #1652
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>
2019-08-06 16:50:49 +00:00
Aleksey Kladov
deea8f52d9 allow to exclude certain files and directories 2019-08-06 14:28:31 +02:00
Kirill Bulatov
c5598d9ade Avoid shared mutable state 2019-08-05 23:11:16 +03:00
Kirill Bulatov
777552b6a8 Cache decorations before the first change only 2019-08-05 13:41:02 +03:00
Kirill Bulatov
f358b4c0c0 Use WeakMap to avoid memory leaks 2019-08-05 11:14:18 +03:00
Kirill Bulatov
3fb6462d54 Style and test fixes 2019-08-05 01:02:36 +03:00
Kirill Bulatov
2c02aebeb5 Query less hints on file open 2019-08-05 00:23:58 +03:00
bors[bot]
78317383c9 Merge #1614
1614: show prettier diff on CI r=matklad a=matklad



Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
2019-07-29 08:55:09 +00:00
Aleksey Kladov
605b2983ef show prettier diff on CI 2019-07-29 11:54:37 +03:00
bors[bot]
e2f65f61af Merge #1610
1610: Ignore cancelled inlay hints responses r=matklad a=SomeoneToIgnore

Fixes #1607

Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
2019-07-29 08:40:17 +00:00
Aleksey Kladov
c1dcdd4735 ⬆️ npm 2019-07-29 11:22:56 +03:00
Kirill Bulatov
4924867b3b Style fixes 2019-07-29 11:19:13 +03:00
Kirill Bulatov
b133a3b55c Ignore cancelled inlay hints responses 2019-07-29 10:19:35 +03:00
Florian Diebold
00c74b5d18 Implement inlay hints for emacs 2019-07-27 11:02:34 +02:00
Kirill Bulatov
f1ba963a30 npm run fix 2019-07-25 16:20:02 +03:00
Kirill Bulatov
02f18abc55 Code review fixes 2019-07-25 15:43:35 +03:00
Kirill Bulatov
bd904247ba Remove unnecessary hacks 2019-07-25 15:17:28 +03:00
Kirill Bulatov
583f5c9612 Fix linter issues 2019-07-25 15:17:28 +03:00
Kirill Bulatov
f7b8ae1ee7 Simplify the hints display 2019-07-25 15:17:28 +03:00
Kirill Bulatov
169e69d217 Show type decorators 2019-07-25 15:17:28 +03:00
Aleksey Kladov
51568c1467 try to show exact prettier problem 2019-07-25 13:05:34 +03:00
Aleksey Kladov
38f3b47a00 ⬆️ npm deps 2019-07-25 12:17:27 +03:00
Aleksey Kladov
d690249bc8
Remove obsolete keybinding 2019-07-21 19:08:05 +03:00
Aleksey Kladov
e418889996 underline mutable bindings 2019-07-19 15:07:18 +03:00
Ekaterina Babshukova
4abe03879b highlight mutable variables differently 2019-07-18 18:52:50 +03:00
dependabot[bot]
83ab841bfa
Bump lodash from 4.17.11 to 4.17.14 in /editors/code
Bumps [lodash](https://github.com/lodash/lodash) from 4.17.11 to 4.17.14.
- [Release notes](https://github.com/lodash/lodash/releases)
- [Commits](https://github.com/lodash/lodash/compare/4.17.11...4.17.14)

Signed-off-by: dependabot[bot] <support@github.com>
2019-07-11 23:44:16 +00:00
kjeremy
45d6f47c28 Update vsce to latest 2019-07-03 09:55:48 -04:00
bors[bot]
bb70d18a0a Merge #1458
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>
2019-06-30 10:17:29 +00:00
bors[bot]
fb2534f300 Merge #1459
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>
2019-06-30 09:54:47 +00:00
Ryan Cumming
067ca38ecb Consider unreachable code to be unnecessary in VSC
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.
2019-06-30 12:13:56 +10:00
Ryan Cumming
8f726b7db6 Include primary span label in VS Code diagnostics
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.
2019-06-30 11:12:56 +10:00
Ryan Cumming
60ba253753 Run VS Code tests on CI
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.
2019-06-30 07:12:42 +10:00
bors[bot]
8865db6768 Merge #1454
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>
2019-06-29 09:50:56 +00:00
Ryan Cumming
50c6ab709e Comment on the key of suggestedFixes
This isn't immediately obvious without looking at the users of the map
2019-06-29 19:46:20 +10:00
Ryan Cumming
c8fc00258d Add noUnusedLocals to VsCode tsconfig
`tslint` doesn't catch this because TypeScript has had this check
builtin since 2.9. However, it's disabled by default so right now
nothing is checking for unused variables.
2019-06-29 18:00:22 +10:00
Ryan Cumming
abc0784e57 Fix cargo watch code action filtering
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.
2019-06-29 17:39:36 +10:00
zbelial
dc7cec8cf4 Add show syntax tree function to emacs 2019-06-29 09:12:16 +08:00
Ryan Cumming
a8a1bc4b15 Extract lint scopes from cargo watch
Currently all of our VS Code diagnostics are given the source of
`rustc`. However, if you have something like `cargo-watch.command` set
to `clippy` it will also watch for Clippy lints. The `rustc` source is a
bit misleading in that case.

Fortunately, Rust's tool lints (RFC 2103) line up perfectly with VS
Code's concept of `source`. This checks for lints scoped to a given tool
and then splits them in to a `source` and tool-specific `code`.
2019-06-27 08:52:22 +10:00
Ryan Cumming
f82ceca0bd Initial Visual Studio Code unit tests
As promised in #1439 this is an initial attempt at unit testing the
VSCode extension. There are two separate parts to this: getting the test
framework working and unit testing the code in #1439.

The test framework nearly intact from the VSCode extension generator.
The main thing missing was `test/index.ts` which acts as an entry point
for Mocha. This was simply copied back in. I also needed to open the
test VSCode instance inside a workspace as our file URI generation
depends on a workspace being open.

There are two ways to run the test framework:

1. Opening the extension's source in VSCode, pressing F5 and selecting
   the "Extensions Test" debug target.

2. Closing all copies of VSCode and running `npm test`. This is started
   from the command line but actually opens a temporary VSCode window to
   host the tests.

This doesn't attempt to wire this up to CI. That requires running a
headless X11 server which is a bit daunting. I'll assess the difficulty
of that in a follow-up branch. This PR is at least helpful for local
development without having to induce errors on a Rust project.

For the actual tests this uses snapshots of `rustc` output from a real
Rust project captured from the command line. Except for extracting the
`message` object and reformatting they're copied verbatim into fixture
JSON files.

Only four different types of diagnostics are tested but they represent
the main combinations of code actions and related information possible.
They can be considered the happy path tests; as we encounter
corner-cases we can introduce new tests fixtures.
2019-06-26 20:31:36 +10:00
Ryan Cumming
5c6ab11453 Tweak isUnusedOrUnnecessary
The first cut was a bit rough with the blanket `unused_*` rule. This
trigger for things like `unused_mut` where the code is used but it's
suboptimal. It's misleading to grey out the code in those cases.
Instead, use an explicit list of things known to be dead code.
2019-06-25 21:44:27 +10:00
Ryan Cumming
d997fd8ea5 Fix comparison of Code Action edit lengths
This happened to work because we always produce a single edit but this
is obviously dubious.
2019-06-25 21:36:55 +10:00
Ryan Cumming
6d6cb25cf4 Rich mapping of cargo watch output
Currently we depend on the ASCII rendering string that `rustc` provides
to populate Visual Studio Code's diagnostic. This has a number of
shortcomings:

1. It's not a very good use of space in the error list
2. We can't jump to secondary spans (e.g. where a called function is
   defined)
3. We can't use Code Actions aka Quick Fix

This moves all of the low-level parsing and mapping to a
`rust_diagnostics.ts`. This uses some heuristics to map Rust diagnostics
to VsCode:

1. As before, the Rust diagnostic message and primary span is used for
   the root diagnostic. However, we now just use the message instead of
   the rendered version.

2. Every secondary span is converted to "related information". This
   shows as child in the error list and can be jumped to.

3. Every child diagnostic is categorised in to three buckets:
    1. If they have no span they're treated as another line of the root
       messages
    2. If they have replacement text they're treated as a Code Action
    3. If they have a span but no replacement text they're treated as
       related information (same as secondary spans).
2019-06-25 21:16:04 +10:00
Aleksei Sidorov
28e9e8d4cf Fix code after "apply suggestions" 2019-06-24 13:50:34 +03:00
Aleksey Sidorov
c40ee089f2
Apply suggestions from code review
Co-Authored-By: Aleksey Kladov <aleksey.kladov@gmail.com>
2019-06-24 13:35:11 +03:00