While VSCode [uses it's own implementation for URIs](https://github.com/microsoft/vscode-uri)
which notably doesn't have any limits of URI size, the renderer itself
relies on Web platform engine, that limits the length of the URLs and
bails out when the attribute length of an `href` inside `a` tag is too
long.
Command URIs have a form of `command:command-name?arguments`, where
`arguments` is a percent-encoded array of data we want to pass along to
the command function. For "Show References" this is a list of all file
URIs with locations of every reference, and it can get quite long.
This PR introduces another intermediary `linkToCommand` command. When
we render a command link, a reference to a command with all its arguments
is stored in a map, and instead a `linkToCommand` link is rendered
with the key to that map.
For now the map is cleaned up periodically (I've set it to every
10 minutes). In general case we'll probably need to introduce TTLs or
flags to denote ephemeral links (like these in hover popups) and
persistent links and clean those separately. But for now simply keeping
the last few links in the map should be good enough. Likewise, we could
add code to remove a target command from the map after the link is
clicked, but assuming most links in hover sheets won't be clicked anyway
this code won't change the overall memory use much.
Closes#9926
Per [bjorn3][https://github.com/bjorn3] suggestion resolves cases where
an early return is moved to a separate line due to line width formatting.
This setting changes
```
if (a very long condition) return;
```
to
```
if (a very long
condition) {
return;
}
```
while keeping
```
if (short) return;
```
as is.
In pathological cases this may cause `npm run fix` not to fix formatting
in one go and may require running it twice.
feat: Support variable substitution in VSCode settings
Currently support a subset of [variables provided by VSCode](https://code.visualstudio.com/docs/editor/variables-reference) in `server.extraEnv` section of Rust-Analyzer settings:
* `workspaceFolder`
* `workspaceFolderBasename`
* `cwd`
* `execPath`
* `pathSeparator`
Also, this PR adds support for general environment variables resolution. You can declare environment variables and reference them from other variables like this:
```JSON
"rust-analyzer.server.extraEnv": {
"RUSTFLAGS": "-L${env:OPEN_XR_SDK_PATH}",
"OPEN_XR_SDK_PATH": "${workspaceFolder}\\..\\OpenXR-SDK\\build\\src\\loader\\Release"
},
```
The order of variable declaration doesn't matter, you can reference variables before defining them. If the variable is not present in `extraEnv` section, VSCode will search for them in your environment. Missing variables will be replaced with empty string. Circular references won't be resolved and will be passed to rust-analyzer server process as is.
Closes#9626, but doesn't address use cases where people want to use values provided by `rustc` or `cargo`, such as `${targetTriple}` proposal #11649
First, we go through every environment variable key and record all cases
where there are reference to other variables / dependencies.
We track two sets of variables - resolved and yet-to-be-resolved.
We pass over a list of variables over and over again and when all
variable's dependencies were resolved during previous passes we perform
a replacement for that variable, too.
Over time the size of `toResolve` set should go down to zero, however
circular dependencies may prevent that. We track the size of `toResolve`
between iterations to avoid infinite looping.
At the end we produce an object of the same size and shape as
the original, but with the values replace with resolved versions.
Assuming ID=linux in isNixOs by default. You can get away with
default "", but why do that if there's a default value in spec?)
Also removed toLowerCase — it really shouldn't be needed.
Fixes#11709
- 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.
