feature: Support standalone Rust files #8955

SomeoneToIgnore · 2021-05-23T21:38:23Z

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.

matklad

I like this!

But let's add the following as a comment on DetachedFiles, as a sort of extended TODO:

The primary limitation of this approach is that the set of detached files needs to be fixed at the beginning. That's not the end user experience we should strive for. Ideally, you should be able to just open a random detached file in existing cargo projects, and get the basic features working. That needs some changes on the salsa-level though. In particular, we should split the unified CrateGraph (which currently has maximal durability) into proper crate graph, and a set of ad hoc roots (with minimal durability). Then, we need to hide the graph behind the queries such that most queries look only at the proper crate graph, and fall back to ad hoc roots only if there's no results. After this, we should be able to tweak the logic in reload.rs to add newly opened files, which don't belong to any existing crates, to the set of the detached files.

crates/project_model/src/sysroot.rs

matklad · 2021-05-24T10:29:53Z

editors/code/src/main.ts

+        if (rustDocuments.length > 0) {
+            ctx = await Ctx.create(config, context, serverPath, { kind: 'Detached Files', files: rustDocuments });
+        } else {
+            throw new Error("no rust files are opened");


Oh, didn't realize we still have this vscode.workspace.workspaceFolders?.[0] logic on the client side. It's wrong and should be removed (unrelated to this PR of course)

Time to break the client again, I guess.

What should be the alternative?
const target = vscode.workspace.workspaceFolders![0]; // safe, see main activate()
?

As usual, just don't do it at all :-)

We use workspace folder for two things:

to set cwd for the server

in task provider

The serever is not relying on cwd (we are careful with using AbsPaths everywhere), so, presumably, that logic can be removed.

The tasks should be fixed to collect the task from all workspace folders, and not just from the first one.

to set cwd for the server

I feel that could be connected with the debug.ts logic (it's a 3rd place where we use vscode.workspace.workspaceFolders), but I'll give it a try and check how it goes.

Not doing anything in this PR, just in case.

Co-authored-by: Aleksey Kladov <[email protected]>

SomeoneToIgnore · 2021-05-24T11:53:25Z

That's not the end user experience we should strive for.

Agree, that's why I added multiple files into the DetachedFiles variant.
Yet I'm not sure how to react on the dynamic file opening in VSCode to start hacking with the server side 😞
I'll dig more later.

Meanwhile, the FIXME is added.

matklad · 2021-05-24T12:40:11Z

bors r+

bors · 2021-05-24T12:50:07Z

Build succeeded:

8995: fix: Create tasks for all workspaces r=matklad a=SomeoneToIgnore Follow-up of #8955 (comment) Before: <img width="593" alt="image" src="https://user-images.githubusercontent.com/2690773/119575267-712b5300-bdbf-11eb-833c-f688f7a7dd0f.png"> After: <img width="643" alt="image" src="https://user-images.githubusercontent.com/2690773/119575273-74264380-bdbf-11eb-8283-a78bbcb7346e.png"> This is the first time I've used multiple workspaces feature in VSCode, but so far looks like * opening detached files works * run and debug lens work * Rust Analyzer: Run action works * run task works and now shows tasks for all workspaces * there are no platform-specific changes involved Co-authored-by: Kirill Bulatov <[email protected]>

boehs · 2021-05-31T17:20:03Z

Thank you. Thank you so much. I am on the verge of tears.

runiq · 2021-06-10T18:09:33Z

So I tried to enable this in Neovim; and I'm still getting "Failed to discover workspace" with the newest r-a release (which should have #9091 included). It seems that #9091 implies some required support in the LSP client?

SomeoneToIgnore · 2021-06-10T18:13:30Z

Currently the r-a server requires detachedFiles with the absolute paths to the standalone files passed as a field of the initialization options: https://github.com/rust-analyzer/rust-analyzer/pull/8955/files#diff-bca0ed357f47caaadd008edc9b2df19f36869583b78c2c0265b9f0db3650df2eR54

boehs · 2021-06-11T20:30:51Z

Currently the r-a server requires detachedFiles with the absolute paths to the standalone files passed as a field of the initialization options: https://github.com/rust-analyzer/rust-analyzer/pull/8955/files#diff-bca0ed357f47caaadd008edc9b2df19f36869583b78c2c0265b9f0db3650df2eR54

How can I, as a rust analyzer user, fix this? I use RA vscode

SomeoneToIgnore · 2021-06-11T20:45:09Z

I don't think there's anything to fix in my quote, this is the way it works in vscode currently: if you use a server that's new enough, it's able to accept and process this parameter; if you use vscode plugin that's new enough, it's able to send this parameter when a detached file is opened with the code foo.rs way.
On my OS, it currently works with the freshmost nightly plugin and server.

If you have any issues with opening a detached file via code command, I suggest filing a separate issue with the details.

If you want to support arbitrary detached files being dynamically added to an already open vscode instance, that's not supported currently and will require plenty of changes along the way (protocol extensions to let the server dynamically know about the new files, server side refactoring for better dynamic project update and the feature implementation itself) and won't happen in the near future unless somebody works on that.

boehs · 2021-06-12T02:39:12Z

Thank you, the dynamic opening is likely my issue, good to know the solution.

* Some language servers *cough*rust-analyzer*cough* need an empty/custom workspaceFolders for certain usecases. For example, rust-analyzer needs an empty workspaceFolders table for standalone file support (See rust-lang/rust-analyzer#8955). * This can also be useful for other languages that need to commonly open a certain directory (like flutter or lua), which would help prevent spinning up a new language server altogether. * In case no workspaceFolders are passed, we fallback to what we had before.

…15132) Some language servers *cough*rust-analyzer*cough* need an empty/custom workspaceFolders for certain usecases. For example, rust-analyzer needs an empty workspaceFolders table for standalone file support (See rust-lang/rust-analyzer#8955). This can also be useful for other languages that need to commonly open a certain directory (like flutter or lua), which would help prevent spinning up a new language server altogether. In case no workspaceFolders are passed, we fallback to what we had before.

oblitum · 2021-09-09T13:39:21Z

I have standalone cargo-less files working in coc-rust-analyzer, added dynamically (got just a single r-a instance running for multiple, file-path unrelated, rust files opened after the first one: cd /tmp/a/, nvim foo.rs, :e ../b/bar.rs, :e ../c/baz.rs, etc).

coc-rust-analyzer has once added support for this newer DetachedFiles feature, but it has been eventually amended on top of a late more fundamental change at workspace detection in core coc.nvim that would send null when a workspace folder isn't inferred (which is backed by spec at: "It can be null if the client supports workspace folders but none are configured").

So I assume r-a works just fine for standalone files when receiving null as workspaceFolders? Regardless of the DetachedFiles feature? It seems to me these two points in the spec intersect somehow.

EDIT:

See newer test bellow, this one is actually invalid.

SomeoneToIgnore · 2021-09-09T13:53:57Z

I've experimented with similar thing in VSCode: it can react on any file that's open in the current editor and try to resolve that opened file's path against current workspace, either returning the relative(?) path for workspace files or null for failed resolutions.

If I'm not mistaken, you describe the same functionality.
The main culprit here is the fact, that there's files that are not the part of the VSCode workspace, that are part of cargo workspace: any stdlib file sources, any crate file sources or their dependencies' sources: they are usually all installed into directories that are different from what the current VSCode workspace includes, so null will be returned for such.

But rust-analyzer already has a proper crate metadata for such files, and adding those as standalone files would be weird at best, if not breaking.

More complexity adds the fact that VSCode API operates FS pathes whereas current cargo graph (same as the majority things in rust-analyzer) is pretty distant from any FS abstractions: to support a "is this detached file actually from some crate in the tree" check, you'll have to change the server codebase.

…eovim#15132) Some language servers *cough*rust-analyzer*cough* need an empty/custom workspaceFolders for certain usecases. For example, rust-analyzer needs an empty workspaceFolders table for standalone file support (See rust-lang/rust-analyzer#8955). This can also be useful for other languages that need to commonly open a certain directory (like flutter or lua), which would help prevent spinning up a new language server altogether. In case no workspaceFolders are passed, we fallback to what we had before.

oblitum · 2021-10-23T13:19:42Z

I want to amend the information in the test above, it's invalid, and repeat the test with valid information, I think this is potentially pretty relevant to r-a's support of standalone cargo-less files. r-a seems to actually fit almost the same case as metals, except that it exceptionally works for files opened on start (nvim a/foo.rs), but not for files opened afterwards (:e b/bar.rs). What happened in my previous test is that coc.nvim actually has sent /tmp/a as the workspace directory, instead of sending null, and this seems the reason that made r-a "to work" on all the files, this behavior of coc.nvim is actually an issue (see neoclide/coc.nvim#3375), I expected it to have sent null, but it did not, it just do that in a hard-coded case at the moment, which is when files are opened from home directory. So, without further ado, let's redo this test while opening files from home, which allows us to asses r-a's behavior when actually no workspace is being provided:

cd ~
mkdir a
touch a/foo.rs
mkdir b
touch b/bar.rs
nvim a/foo.rs
:CocCommand workspace.workspaceFolders (no workspace folder reported, on previous test this was /tmp/a)
type some code (in foo.rs), you'll see rust analyzer up and working
:e b/bar.rs
:CocCommand workspace.workspaceFolders (no workspace folder reported, on previous test this was /tmp/a)
type some code (in bar.rs), you'll see rust analyzer is absent (differently from previous test on /tmp)

If you apply this test with coc-sh instead of coc-rust-analyzer (for shell files of course), bash-lsp works without problems, because it has no issues providing its services on null workspaces, for standalone files, and without any protocol extension.

(If for some reason the above isn't clear enough, feel free to mail me if you wish a link with a very detailed description of what this is about, which is what made me revisit r-a's case. It may make it clearer where r-a lies in this problem scope)

cc @fannheyward

…eovim#15132) Some language servers *cough*rust-analyzer*cough* need an empty/custom workspaceFolders for certain usecases. For example, rust-analyzer needs an empty workspaceFolders table for standalone file support (See rust-lang/rust-analyzer#8955). This can also be useful for other languages that need to commonly open a certain directory (like flutter or lua), which would help prevent spinning up a new language server altogether. In case no workspaceFolders are passed, we fallback to what we had before.

arryhere · 2023-05-21T15:46:14Z

is there a guide on how to enable all this is vs-code ? no one seems to talk about it on how to actually use it..

SomeoneToIgnore · 2023-05-21T16:31:07Z

all this

There's nothing but the ability to open a standalone file with code, as code foo.rs
Works for me still:

Due to impl limitations described above, all consequent standalone file opens in the same editor won't work.

UnkwUsr · 2023-07-11T22:03:53Z

Note for neovim users there: you probably should use rust-tools.nvim, as lspconfig won't support this language-specific feature.

srtnnm · 2024-01-19T08:55:47Z

nice job! yeah, it really works
but i can't really understand why rust-analyzer still gives an errors
i think it must be an warning or something like "not in workspace"

koiralakiran1 · 2024-03-27T11:29:18Z

I see that for standalone files, the auto-complete works but some errors/warnings aren't detected. I'm not sure if I'm missing something. For standalone files, some errors like missing semicolons do show up though but others like unknown functions don't.

For cargo project:

For standalone/detached files opened with code test.rs.

I'm running the project on WSL if that matters. I've tried on windows & mac as well to see if there's a difference. I'll use a cargo project moving forward but I'd love to have RA work on a standalone file.

rust-analyzer version: 0.3.1896-standalone

SomeoneToIgnore added 8 commits May 23, 2021 22:46

Start rust-analyzer server for arbitrary rust files

d9a5490

Send detached files info to server via init params

b3383b0

Draft detached files retrieval

695569d

Drag detached files towards loading

de09074

Do not add cargo target for detached files only project

2ca2e24

Deal with todos

72594be

Fix ts lint errors

c1f6a5a

Don't discover workspaces when detached files are given

b5f524c

matklad reviewed May 24, 2021

View reviewed changes

SomeoneToIgnore and others added 2 commits May 24, 2021 14:47

Small file error display fix

d8c3602

Co-authored-by: Aleksey Kladov <[email protected]>

Add a FIXME

5c0369b

bors bot merged commit 05fc97e into rust-lang:master May 24, 2021

SomeoneToIgnore deleted the open-single-files branch May 24, 2021 12:50

SomeoneToIgnore mentioned this pull request May 25, 2021

fix: Create tasks for all workspaces #8995

Merged

emi2k01 mentioned this pull request Jun 20, 2021

Standalone file support simrat39/rust-tools.nvim#25

Closed

simrat39 mentioned this pull request Jul 19, 2021

lsp(start_client): Allow passing custom workspaceFolders to the LSP neovim/neovim#15132

Merged

ghost mentioned this pull request Aug 1, 2021

Support for standalone files (no Cargo.toml) fannheyward/coc-rust-analyzer#828

Closed

SomeoneToIgnore mentioned this pull request Aug 31, 2021

fix: Remove incorrectly filtering VS Code cargo task execution resolution by scope #10093

Merged

jadestrong mentioned this pull request Oct 12, 2021

Can lsp-rust (rust-analyzer) also support standalone rust file? emacs-lsp/lsp-mode#3146

Closed

ksqsf mentioned this pull request Feb 24, 2022

Feature Request: rust-analyzer standalone file support brotzeit/rustic#391

Closed

EJammy mentioned this pull request Apr 24, 2022

Support standalone files for rust-analyzer neovim/nvim-lspconfig#1854

Closed

PeterCardenas mentioned this pull request Jun 14, 2022

No rust completion for unlinked or standalone files ycm-core/YouCompleteMe#4034

Closed

12 tasks

hiberabyss mentioned this pull request Aug 1, 2022

[rust-analyzer] not work with single rust file mason-org/mason.nvim#216

Closed

2 tasks

mikayla-maki mentioned this pull request Oct 28, 2022

User Frictions zed-industries/zed#1706

Closed

40 tasks

JosephTLyons mentioned this pull request Oct 28, 2022

Support standalone Rust files zed-industries/zed#5159

Open

1 task

istudyatuni mentioned this pull request Nov 5, 2022

Language server didn't start for standalone files sublimelsp/LSP-rust-analyzer#83

Open

matklad mentioned this pull request Dec 2, 2022

Feature Req: Add support for Rust files without Cargo.toml or valid cargo workspaces #4477

Closed

SomeoneToIgnore mentioned this pull request Jan 26, 2023

Inlay Hint Support zed-industries/zed#5482

Closed

anstadnik mentioned this pull request Jul 28, 2023

How to configure to attach a rust lsp client for single file helix-editor/helix#5142

Closed

victor-timofei mentioned this pull request Aug 7, 2023

Proper support for standalone/detached files #14318

Open

rhjdvsgsgks mentioned this pull request Feb 24, 2024

fix(rust_analyzer): declare single file support neovim/nvim-lspconfig#3028

Merged

saecki mentioned this pull request Mar 8, 2024

Add support for rust-script's in source file dependencies saecki/crates.nvim#111

Open

feature: Support standalone Rust files #8955

feature: Support standalone Rust files #8955

Uh oh!

Conversation

SomeoneToIgnore commented May 23, 2021

Uh oh!

matklad left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

matklad May 24, 2021

Choose a reason for hiding this comment

Uh oh!

SomeoneToIgnore May 24, 2021

Choose a reason for hiding this comment

Uh oh!

matklad May 24, 2021

Choose a reason for hiding this comment

Uh oh!

SomeoneToIgnore May 24, 2021

Choose a reason for hiding this comment

Uh oh!

SomeoneToIgnore commented May 24, 2021

Uh oh!

matklad commented May 24, 2021

Uh oh!

bors bot commented May 24, 2021

Uh oh!

boehs commented May 31, 2021

Uh oh!

runiq commented Jun 10, 2021

Uh oh!

SomeoneToIgnore commented Jun 10, 2021

Uh oh!

boehs commented Jun 11, 2021

Uh oh!

SomeoneToIgnore commented Jun 11, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

boehs commented Jun 12, 2021

Uh oh!

oblitum commented Sep 9, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SomeoneToIgnore commented Sep 9, 2021

Uh oh!

oblitum commented Oct 23, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

arryhere commented May 21, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SomeoneToIgnore commented May 21, 2023

Uh oh!

UnkwUsr commented Jul 11, 2023

Uh oh!

srtnnm commented Jan 19, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

koiralakiran1 commented Mar 27, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

SomeoneToIgnore commented Jun 11, 2021 •

edited

Loading

oblitum commented Sep 9, 2021 •

edited

Loading

oblitum commented Oct 23, 2021 •

edited

Loading

arryhere commented May 21, 2023 •

edited

Loading

srtnnm commented Jan 19, 2024 •

edited

Loading

koiralakiran1 commented Mar 27, 2024 •

edited

Loading