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
![standalone](https://user-images.githubusercontent.com/2690773/119277037-0b579380-bc26-11eb-8d77-20d46ab4916a.gif)
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.
![image](https://user-images.githubusercontent.com/1974256/103236081-bb58f700-493b-11eb-9d12-55ae1b870f8f.png)
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.