rust-analyzer failed to load workspace: can't find Cargo.toml at

[Matelasse]

It's a good message, but it assumes every folder I open is a Rust workspace. Can we disable it?

[matklad]

It should trigger only for folders with Rust code, if it triggers for literally every folder, then it's a bug. There's no flag to disable this message, but there should be one!

The relevant code is here:

https://github.com/rust-analyzer/rust-analyzer/blob/4444192b05c107a40a5a05ea3c9091ad8f8cbbcc/crates/ra_lsp_server/src/main_loop.rs#L76-L80

First, we should distinguish between "no Cargo.toml" and "some other error" cases (it would be bad to supress messages about, say, invalid syntax in toml). Then, we should add a flag to disable the firtst message.

A similar flag exists here: https://github.com/rust-analyzer/rust-analyzer/blob/4444192b05c107a40a5a05ea3c9091ad8f8cbbcc/crates/ra_lsp_server/src/main_loop.rs#L372-L375

[matklad]

A related issue is that we should allow one to configure location of Cargo.toml within worksapce. We currently assume it's in the root.

[detrumi]

This can be closed: there's the notifications.cargo-toml-not-found feature flag now.

[kankri]

It should trigger only for folders with Rust code, if it triggers for literally every folder,
then it's a bug. There's no flag to disable this message, but there should be one!

I'm not sure I understand why the flag was made and why the issue was closed.

Why is the message there if it needs a flag to be silenced?

What happens for me is that when I start VS Code, it restores my 12 windows, 10 of which have a workspace and 2 of which have just individual files open. The 10 windows with workspaces each contain either JS (1), Python (7), C (1) or Rust (1) files, there are no mixed type workspaces. I get the message

rust-analyzer failed to load workspace: Failed to find Cargo.toml for path <workspace>
Caused by: can't find Cargo.toml at <workspace>, due to no Cargo.toml file found

in all the windows except the one with Rust and, for some reason, the one with Python files. But the real problem is that looking at "Help -> Open Process Explorer" I can see 9 of the windows containing a subprocess of "rust-analyzer-windows.exe" instead of just the one with Rust code!

VS Code eats a lot of CPU when it starts and a lot of memory all the time. I wouldn't want to waste any extra resouces to 8 unnecessary Rust analyzers.

If I open a new window with a folder of say Python files, Rust analyzer doesn't start for it. However, if I restart VS Code, Rust analyzer is running in that window, too. It is the only extension exhibiting this behavior.

I'm currently running VS Code 1.44.2 and rust-analyzer 0.2.151, but the problem has existed for a long time.

I dug deeper and noticed that running code --performance I see that rust-analyzer is activated because the workspaceContains trigger times out:

Extension	Eager	Load Code	Call Activate	Finish Activate	Event	By
matklad.rust-analyzer	true	131	3	51967	workspaceContainsTimeout:**/Cargo.toml	matklad.rust-analyzer

The logic behind this seems to be in line 510 extHostExtensionService.ts and happens when it takes more than AbstractExtHostExtensionService.WORKSPACE_CONTAINS_TIMEOUT (7000ms) to do the search for "**/Cargo.toml".

I'm hoping rust-analyzer could at least ask the user if they want to use the extension when Cargo.toml is not found and kill the subprocess and deactivate the extension, if not. I don't see the need for a flag to hide this question. I think even better would be to deactivate if Cargo.toml is not found and then get reactivated when Cargo.toml or some *.rs file is opened.

I think it would be beneficial for every extension to know why they were activated (e.g. because of timeout or because a particular file matched the search trigger) so I added a comment to that effect in the issue microsoft/vscode#44711.

I think it would also be useful if the search for "Cargo.toml" would not recurse arbitrarily deeply. The issue microsoft/vscode#34711 which added the timeout had some similar suggestions which I think didn't end up being implemented.

That issue also has the comment about the timeout:

We then need to document that workspaceContains should not be relied on
exclusively, which is fair considering how much resources it can take.

[kankri]

I just noticed that the rls extension added commit rust-lang/vscode-rust@61838af which makes the extension more lazily start heavy resources. When I restart VS Code, I don't want the windows which I'm not looking at be fully activated. Only when I start interacting with a window should it become fully operational. Is this something rust-analyzer could implement?

[kankri]

@matklad: Do you want me to create a separate issue about the problem this one raised about rust-analyzer starting and staying loaded for directories not having Cargo.toml, or can you reopen this one?