| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
