Commit Graph

140 Commits

Author SHA1 Message Date
krk
9bbb27604d Add link to the vscode VIM extension compatibility warning. 2019-10-30 21:44:27 +01:00
Aleksey Kladov
dc65219ae1 document feature flags 2019-10-25 09:00:30 +03:00
bors[bot]
d2e1f9f6da
Merge #1980
1980: Shorten inline type hints r=matklad a=detrumi

Implements #1946 

Co-authored-by: Wilco Kusee <wilcokusee@gmail.com>
2019-10-23 11:13:04 +00:00
Wilco Kusee
770bb8dc9b
Do not truncate the range 2019-10-23 13:11:40 +02:00
Wilco Kusee
3b61acb4ae
Make inlay hint length configurable 2019-10-18 13:45:04 +02:00
Roberto Vidal
f4d50de275 Adds config option for cargo-watch --ignore flag 2019-10-17 20:21:07 +02:00
Wilco Kusee
ce4fb06dec
Truncate hints longer than 20 characters 2019-10-10 14:52:05 +02:00
arsdragonfly
17d1405a8b Fix 2019-09-27 20:02:51 -04:00
arsdragonfly
945679e42f Fix tests 2019-09-27 17:33:14 -04:00
arsdragonfly
d1988a17f4 Support the new deprecated tag 2019-09-27 16:17:02 -04:00
Lucas Spits
80b45d5928
Replace watcher file existence check with vscode.fs version 2019-09-09 20:24:31 +02:00
Aleksey Kladov
28df377759 add option to disable notify 2019-09-06 17:21:29 +03:00
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
xfoxfu
d07a85ed7e fix #1424
resolve "~" in raLspServerPath
2019-08-19 10:48:39 +08: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
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
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
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
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
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
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
Aleksei Sidorov
b1bc629b83 Fix tslints 2019-06-24 13:33:37 +03:00
Aleksei Sidorov
4722e6d491 Introduce cargo-watch.check-command 2019-06-24 13:02:20 +03:00
Aleksey Kladov
fed52706de make LRU cache configurable 2019-06-12 13:36:24 +03:00
Pascal Hertleif
1e6ba19015 Make rainbows optional 2019-05-27 11:44:46 +02:00