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.
[Prettier][1] is an up-to date code formatter for JavaScript ecosystem.
For settings we rely on [EditorConfig][2] for things like tab style and
size (with added bonus that the code editor with an EditorConfig plugin
does some automated code formatting on file save for you). Unfortunately,
Prettier's Glob handling isn't great:
1. `*.{ts,js,json}` has no effect
2. Similarly, in a list of globs `*.ts,*.js,*.json` only the first glob
has an effect, the rest are ignored.
That's why the file looks the way it does.
The only other setting we change is line width. [Lukas][3] suggested we
use 100 instead of 80, because that's what Rustfmt is using.
[1]: https://prettier.io
[2]: https://editorconfig.org
[3]: https://github.com/Veykril
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.
