- Allow the zoom to go further than 10x
- Adapt css to dark and high constrast themess
- Use 'javascript/worker' for the wasm graphviz
- Add Ctrl + LeftMouseClick to reset zoom
Some features of rust-analyzer requires support for custom commands on
the client side. Specifically, hover & code lens need this.
Stock LSP doesn't have a way for the server to know which client-side
commands are available. For that reason, we historically were just
sending the commands, not worrying whether the client supports then or
not.
That's not really great though, so in this PR we add infrastructure for
the client to explicitly opt-into custom commands, via `extensions`
field of the ClientCapabilities.
To preserve backwards compatability, if the client doesn't set the
field, we assume that it does support all custom commands. In the
future, we'll start treating that case as if the client doesn't support
commands.
So, if you maintain a rust-analyzer client and implement
`rust-analyzer/runSingle` and such, please also advertise this via a
capability.
8951: internal: migrate to vscode.FileSystem API r=matklad a=wxb1ank
I encountered an error where `bootstrap()` attempts to create a directory with the path `C:\C:\...`. I couldn't find this reported anywhere else. Using the `vscode.FileSystem` API instead of the `fs` one works here. I assume the latter automatically prepends `C:\` to paths whereas the former does not. I don't know if this suggests `vscode.FileSystem` should be used in more places for consistency.
Co-authored-by: wxb1ank <wxblank@gmail.com>
8955: feature: Support standalone Rust files r=matklad a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/6388
Caveats:
* I've decided to support multiple detached files in the code (anticipating the scratch files), but I found no way to open multiple files in VSCode at once: running `code *.rs` makes the plugin to register in the `vscode.workspace.textDocuments` only the first file, while code actually displays all files later.
Apparently what happens is the same as when you have VSCode open at some workplace already and then run `code some_other_file.rs`: it gets opened in the same workspace of the same VSCode with no server to support it.
If there's a way to override it, I'd appreciate the pointer.
* No way to toggle inlay hints, since the setting is updated for the workspace (which does not exist for a single file opened)
> [2021-05-24 00:22:49.100] [exthost] [error] Error: Unable to write to Workspace Settings because no workspace is opened. Please open a workspace first and try again.
* No runners/lens to run or check the code are implemented for this mode.
In theory, we can detect `rustc`, run it on a file and run the resulting binary, but not sure if worth doing it at this stage.
Otherwise imports, hints, completion and other features work.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
8624: Automatically detect rust library source file map r=vsrs a=vsrs
This PR adds a new possible `rust-analyzer.debug.sourceFileMap` value:
```json
{
"rust-analyzer.debug.sourceFileMap": "auto"
}
```
I did not make it the default because it uses two shell calls (`rustc --print sysroot` and `rustc -V -v`). First one can be slow (https://github.com/rust-lang/rustup/issues/783)
Fixes#8619
Co-authored-by: vsrs <vit@conrlab.com>
If path to original file contains space (I.e on code insiders, where
default data directory is ~/Code - Insiders/), then there is syntax
error evaluating src arg.
Instead pass path as str, and coerce to path back in nix expression
Signed-off-by: Yaroslav Bolyukin <iam@lach.pw>
7068: Add VSCode command to view the hir of a function body r=theotherphil a=theotherphil
Will fix https://github.com/rust-analyzer/rust-analyzer/issues/7061. Very rough initial version just to work out where I needed to wire everything up.
@matklad would you be happy merging a hir visualiser of some kind? If so, do you have any thoughts on what you'd like it show, and how?
I've spent very little time on this thus far, so I'm fine with throwing away the contents of this PR, but I want to avoid taking the time to make this more polished/interactive/useful only to discover that no-one else has any interest in this functionality.
Co-authored-by: Phil Ellison <phil.j.ellison@gmail.com>
7001: Add support for downloading aarch64-apple-darwin binaries r=matklad a=lnicola
There's also a slight behavior change here: we no longer download our 64-binaries on 32-bit Darwin and Linux. We still do that on Windows, as I don't know how to detect 32-bit Node on 64 Windows.
But some people install the 32-bit Code by mistake, I doubt 32-bit Windows is that popular in the Rust crowd.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
The motivation in #5641 isn't too strong, but /etc/os-release exists on
pretty much every Linux distro, while /etc/nixos sounds like an
implementation detail.
Currently a method only has defaultness if it is a provided trait
method, but this will change when specialisation is available and may
need to become a concept known to hir.
I opted to go for a 'fewest changes' approach given specialisation is
still under development.
The previous version would have interpreted an empty token as
an abort of the dialog and would have not properly cleared the token.
This is now fixed by checking for `undefined` for a an abort and
by setting the token to `undefined` in order to clear it.
This change allows to use a authorization token provided by Github in
order to fetch metadata for a RA release. Using an authorization token
prevents to get rate-limited in environments where lots of RA users use
a shared client IP (e.g. behind a company NAT).
The auth token is stored in `ExtensionContext.globalState`.
As far as I could observe through testing with a local WSL2 environment
that state is synced between an extension installed locally and a remote
version.
The change provides no explicit command to query for an auth token.
However in case a download fails it will provide a retry option as well
as an option to enter the auth token. This should be more discoverable
for most users.
Closes#3688
5910: Fix some typos r=matklad a=SomeoneToIgnore
5912: Remove fixme from inlay_hints.ts r=matklad a=Veetaha
I have reevaluated the fixme and it doesn't seem necessary to pass an array of files
to the inlay hints request.
This will (a) make the request more compilcated (b), make us wait for
inlay hints for `all` active editors resolve at once before rendering and (c)
doesn't seem required because 99% of the time there is a single active editor
in the IDE
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
I have reevaluated the fixme and it doesn't seem necessary to pass an array of files
to the inlay hints request.
This will (a) make the request more compilcated (b), make us wait for
inlay hints for `all` active editors resolve at once before rendering and (c)
doesn't seem required because 99% of the time there is a single active editor
in the IDE
No we return ContentModified during the workspace loading. This signifies the language
client to retry the operation (i.e. the client will
continue polling the server while it returns ContentModified).
I believe that there might be cases of overly big projects where the backoff
logic we have setup in `sendRequestWithRetry` (which we use for inlay hints)
might bail too early (currently the largest retry standby time is 10 seconds).
However, I've tried on one of my project with 500+ dependencies and it is still enough.
5513: Try figure out correct workspace in vscode multi root workspace r=vsrs a=urbandove
the code to replace the root with the `${workspaceRoot}` arg breaks in multi root workspaces as it needs a qualifier `${workspaceRoot:workspaceName}`
This PR attempts to figure out the root workspace - and if it cant find it falls back to the first workspace
Co-authored-by: Urban Dove <urbandove80@gmail.com>
5480: Fix snippetTextEdits applying to other files r=matklad a=TimoFreiberg
Fixes#4551
`vscode.window.visibleTextEditors` only contains editors whose contents are being displayed at the moment, so the previous logic only worked if the other file for which a snippetTextEdit is being received was visible in a separate split.
I feel that this is a hacky approach, so feel free to reject it for something nicer :)
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
vscode.window.visibleTextEditors only contains editors whose contents
are being displayed at the moment, so the previous logic only worked if
the other file for which a snippetTextEdit is being received was visible
in a separate split.
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
Override miniz_oxide to build it with optimizations
Building this crate with optimizations decreases the gzipping
part of `cargo xtask dist` from `30-40s` down to `3s`,
the overhead for `rustc` to apply optimizations is miserable on this background
5202: Runnable env r=matklad a=vsrs
This PR adds on option to specify (in the settings.json) environment variables passed to the runnable.
The simplest way for all runnables in a bunch:
```jsonc
"rust-analyzer.runnableEnv": {
"RUN_SLOW_TESTS": "1"
}
```
Or it is possible to specify vars more granularly:
```jsonc
"rust-analyzer.runnableEnv": [
{
// "mask": null, // null mask means that this rule will be applied for all runnables
env: {
"APP_ID": "1",
"APP_DATA": "asdf"
}
},
{
"mask": "test_name",
"env": {
"APP_ID": "2", // overwrites only APP_ID
}
}
]
```
You can use any valid RegExp as a mask. Also note that a full runnable name is something like *run bin_or_example_name*, *test some::mod::test_name* or *test-mod some::mod*, so it is possible to distinguish binaries, single tests, and test modules with this masks: `"^run"`, `"^test "` (the trailing space matters!), and `"^test-mod"` respectively.
Fixes#4450
I suppose this info should be somewhere in the docs, but unsure where is the best place.
Co-authored-by: vsrs <vit@conrlab.com>
5089: Disable auto-complete on comments r=matklad a=BGluth
Resolves#4907 by disabling any auto-completion on comments.
As flodiebold [pointed out](https://github.com/rust-analyzer/rust-analyzer/issues/4907#issuecomment-648439979), in the future we may want to support some form of auto-completion within doc comments, but for now it was suggested to just disable auto-completion on them entirely.
The implementation involves adding a new field `is_comment` to `CompletionContext` and checking if the immediate token we auto-completed on is a comment. I couldn't see a case where we need to check any of the ancestors, but let me know if this is not sufficient. I also wasn't sure if it was necessary to add a new field to this struct, but I decided it's probably the best option if we want to potentially do auto-completion on doc comments in the future.
Finally, the three tests I added should I think ideally not filter results by `CompletionKind::Keyword`, but if I want to get unfiltered results, I need access to a non-public function [get_all_completion_items](9a4d02faf9/crates/ra_ide/src/completion/test_utils.rs (L32-L39)) which I don't know if I should make public just for this.
5161: SSR: Add initial support for placeholder constraints r=matklad a=davidlattimore
5184: Always install required nightly extension if current one is not nightly r=matklad a=Veetaha
This is weird, but having switched back to stable by uninstalling the extension appears that vscode doesn't destroy the `PersistentState` and thus changing to `nightly` channel doesn't work because the last check for nightly extension was less than 1 hour ago. The simple solution is to skip this check if we know that the current extension version is not nightly.
5185: Force showing extension activation error pop-up notification r=matklad a=Veetaha
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/5091
5186: fix: correct pd/ppd/tfn/tmod completion doc r=matklad a=fannheyward
a33eefa3b2/crates/ra_ide/src/completion/complete_snippet.rs (L23-L24)
Co-authored-by: BGluth <gluthb@gmail.com>
Co-authored-by: David Lattimore <dml@google.com>
Co-authored-by: Veetaha <veetaha2@gmail.com>
Co-authored-by: Heyward Fann <fannheyward@gmail.com>
5101: Add expect -- a light-weight alternative to insta r=matklad a=matklad
This PR implements a small snapshot-testing library. Snapshot updating is done by setting an env var, or by using editor feature (which runs a test with env-var set).
Here's workflow for updating a failing test:
Here's workflow for adding a new test:
Note that colorized diffs are not implemented in this PR, but should be easy to add (we already use them in test_utils).
Main differences from insta (which is essential for rust-analyzer development, thanks @mitsuhiko!):
* self-updating tests, no need for a separate tool
* fewer features (only inline snapshots, no redactions)
* fewer deps (no yaml, no persistence)
* tighter integration with editor
* first-class snapshot object, which can be used to write test functions (as opposed to testing macros)
* trivial to tweak for rust-analyzer needs, by virtue of being a workspace member.
I think eventually we should converge to a single snapshot testing library, but I am not sure that `expect` is exactly right, so I suggest rolling with both insta and expect for some time (if folks agree that expect might be better in the first place!).
# Editor Integration Implementation
The thing I am most excited about is the ability to update a specific snapshot from the editor. I want this to be available to other snapshot-testing libraries (cc @mitsuhiko, @aaronabramov), so I want to document how this works.
The ideal UI here would be a code action (💡). Unfortunately, it seems like it is impossible to implement without some kind of persistence (if you save test failures into some kind of a database, like insta does, than you can read the database from the editor plugin). Note that it is possible to highlight error by outputing error message in rustc's format. Unfortunately, one can't use the same trick to implement a quick fix.
For this reason, expect makes use of another rust-analyzer feature -- ability to run a single test at the cursor position. This does need some expect-specific code in rust-analyzer unfortunately. Specifically, if rust-analyzer notices that the cursor is on `expect!` macro, it adds a special flag to runnable's JSON. However, given #5017 it is possible to approximate this well-enough without rust-analyzer integration. Specifically, an extension can register a special runner which checks (using regexes) if rust-anlyzer runnable covers text with specific macro invocation and do special magic in that case.
closes#3835
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
5119: Show notification while SSR is in progress r=matklad a=davidlattimore
Ideally we would (a) show progress and (b) allow cancellation, but at least now there's some indication to the user that something is happening.
Co-authored-by: David Lattimore <dml@google.com>
Temp dirs are messy. Dealing with them requires handling quite a bunch of
edge cases. As proposed by lnicola this seems better to just put the temp files
in the extension dir and not care much about suddenly leaving garbage.
Instead we get shorter and less platform-caveat-y code.
We will also assume users don't try to issue a download in different vscode windows simultaneously
4992: Never disable error logging on the frontend r=matklad a=Veetaha
4993: Make bootstrap error message more informative and better-fitting r=matklad a=Veetaha
Now this better fits standard vscode extension activation failure message and suggests enabling verbose logs.
4994: Decouple http file stream logic from temp dir logic r=matklad a=Veetaha
Followup for #4989
4997: Update manual.adoc r=matklad a=gwutz
GNOME Builder (Nightly) supports now rust-analyzer
4998: Disrecommend trace.server: "verbose" for regular users r=matklad a=Veetaha
This option has never been useful for me, I wonder if anyone finds regular users can use this for sending logs
Co-authored-by: Veetaha <veetaha2@gmail.com>
Co-authored-by: Günther Wagner <info@gunibert.de>
4580: Fix invoking cargo without consulting CARGO env var or standard installation paths r=matklad a=Veetaha
Followup for #4329
The pr essentially fixes [this bug](https://youtu.be/EzQ7YIIo1rY?t=2189)
cc @lefticus
Co-authored-by: veetaha <veetaha2@gmail.com>
This is useful when an extension (e.g. Nix Environment Selector) or launch
configuration sets one or more environment variables.
When `env` is not explicitly specified in the options passed to
`child_process.spawn()` or `vscode.ShellExecution()`, then `process.env` gets
applied automatically. But when an explicit `env` is set, it should inherit from
`process.env` rather than replace it completely.
As per matklad, we now pass the responsibility for finding the binary to the frontend.
Also, added caching for finding the binary path to reduce
the amount of filesystem interactions.
