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.
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.
Very simple approach: For each identifier, set the hash of the range
where it's defined as its 'id' and use it in the VSCode extension to
generate unique colors.
Thus, the generated colors are per-file. They are also quite fragile,
and I'm not entirely sure why. Looks like we need to make sure the
same ranges aren't overwritten by a later request?
This fixes#1005.
Defaults to `ask` which prompts users each time whether to start `cargo watch`
or not. `enabled` always starts `cargo watch` and `disabled` does not.
This allows users to control whether or not they want to see the "workspace
loaded" notification.
This is done on the server side using InitializationOptions which are provided
by the client. By default show_workspace_loaded is true, meaning the
notification is sent.
This enables the client to use a command to either show the live-updating
version of the syntax tree for the current file. Or optionally when a selected
range is provided, we then provide a snapshot of the syntax tree for the range.
This further fixes problems when having a VIM extension (at least vscodevim)
enabled, by not calling `overrideCommand('type', commands.onEnter.handle)` when
enableEnhancedTyping is set to `false`.
The problem is dependent on the order in which extensions are activated, if
rust-analyzer is activated before `vscodevim`, rust-analyzer will register the
`type` command, and when `vscodevim` finally attempts to activate, it will fail
to register the command. This causes `vscodevim` to stop working properly.
This setting allows users to disable the registerCommand `type` in
rust-analyzer, allowing `vscodevim` to work. The setting defaults to `true`.
Currently changing the setting requires reloading of the window.
Private stops npm publish working, which would be nonsensical anyway
In case it gets added to the vscode extension repository, preview marks it as such
Private may also prevent publishing to the vscode extension repository
