Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"rust-analyzer failed to discover workspace" could be so much more helpful #13226

Open
matklad opened this issue Sep 12, 2022 · 14 comments
Open
Labels
A-rust-project rust-project.json related issues C-enhancement Category: enhancement

Comments

@matklad
Copy link
Member

matklad commented Sep 12, 2022

Today I've got to help a new Rust user to start their Rust project, and our logic to discovering Cargo.tomls was a huge roadblock. Comically gigantic I would say even :)

Basically, the project was in the subdir of the subdir, so nothing worked. But I wasn't able to diagnose on the spot! I had to do the "ok, let's create a new hello-world project and see if it works there" dance to debug this (and it was actually the person whom I was trying to help who said "huh, maybe the problem is that Cargo.toml is in a subdirectory?")

Here's a bunch of ways we can improve this:

  • if there are no projects, we should show red/yellow status.
  • in the status, and in the "rust-analyzer failed to discover workspace" error notification, we should say HOW TO ACTUALLY FIX THE PROBLEM (it's ridiculous that we don't do this, seeing this message from the newbie eyes really is painful)
  • at minimum, we should point at the linked projects settings
  • ideally, as suggested to me, there should be an "open Cargo.toml" link which opens open file dialog
  • and, yeah, it would be cool to suggesting adding Cargo.toml to linked projects if we notice it some time after opening a project (eg, opening a Rust file).
@DrChat
Copy link

DrChat commented Sep 22, 2022

On this line of thought - I had some prototype work that added logic to search for all Cargo.toml manifests in the workspace folder tree and then filter them out using cargo metadata so that ProjectManifest::discover returned all workspace root manifests.
Would something like that be useful for including upstream? Is it too costly to call cargo manifest when scanning for projects?

Also related to #9661

@plwalsh
Copy link

plwalsh commented Oct 3, 2022

@matklad Did something in the extension change recently that now prevents it from auto-discovering projects that aren't at the root of the vscode workspace? I could've sworn it was working fine before the last week or two. But now I see the "failed to discover workspace" message every time I open vscode (with my Rust project is two levels down). I'm on the latest insiders release, with the extension set to the pre-release channel.

@matklad
Copy link
Member Author

matklad commented Oct 3, 2022

We only auto-discover Rust projects one-level deep.

@plwalsh
Copy link

plwalsh commented Oct 3, 2022

@matklad Interesting -- thanks!

@zirconium-n
Copy link

We only auto-discover Rust projects one-level deep.

Could we change this to a configurable depth?

@plwalsh
Copy link

plwalsh commented Oct 9, 2022

Could we change this to a configurable depth?

Yes, please. Something like the recently implemented git.repositoryScanMaxDepth would be great (microsoft/vscode#37947).

Most often, my vscode workspace is a collection of clones, with several of the nested clones being Rust projects. Previously with RLS (before switching to rust-analyzer), all the nested Rust projects would automatically be "discovered", and I'd have access to all the RLS tools any time a Rust file was opened. Now with RA, I have no features available in my opened Rust files. Unfortunately, all my workspaces are different/dynamic, so keeping track of them all as rust-analyzer.linkedProjects isn't really tenable.

@bjorn3
Copy link
Member

bjorn3 commented Oct 9, 2022

For activating the extension, I don't think so. It isn't possible to change the activationEvents of an extension:

"workspaceContains:*/Cargo.toml",
When you open a rust file it should still activate though. For once the extension is activated, possibly:
fn find_cargo_toml_in_child_dir(entities: ReadDir) -> Vec<ManifestPath> {
// Only one level down to avoid cycles the easy way and stop a runaway scan with large projects
entities
.filter_map(Result::ok)
.map(|it| it.path().join("Cargo.toml"))
.filter(|it| it.exists())
.map(AbsPathBuf::assert)
.filter_map(|it| it.try_into().ok())
.collect()
}

@samgqroberts
Copy link

Is there a way to manually resolve this? I have my workspace Cargo.toml a few directories deep in my project. I've scanned the extension settings and can't find a place to manually point rust-analyzer to a Cargo.toml. It seems my only option is to open the subfolder as the root of my VSCode project when I'm working in the Rust portion of it, and switch back to a VSCode window that's at the actual root of my repository for the rest. I've confirmed this works, but it's certainly not ideal.

@matklad
Copy link
Member Author

matklad commented Nov 17, 2022

https://rust-analyzer.github.io/manual.html#rust-analyzer.linkedProjects

@samgqroberts
Copy link

That was it! Thank you @matklad

@Veykril Veykril added A-rust-project rust-project.json related issues C-enhancement Category: enhancement labels Feb 9, 2023
@Astlaan
Copy link

Astlaan commented Feb 22, 2023

I was struggling with strange behaviours from rust-analyzer (sometimes working, others not) for some days, and only now found out this issue of rust projects only being automatically detected on one-level-deep directories.

I think this should be more clear, at least with an error message when no projects are being discovered. But ideally it would probably be useful to allow automatically detecting projects more levels deep by defaulf. If the workspace of the user is too cluttered, he can always exclude folders (such as target etc) from the workspace, or set the depth-level of automatic discovery manually, or set the linkedProjects variable, for example.

@ltfschoen
Copy link

I had a similar situation where I had multiple projects in subdirectories that each had their own Cargo.toml file. I got overcame the error rust-analyzer failed to discover workspace by following the steps that i published here:
https://stackoverflow.com/a/75649115/3208553, so now rust-analyser works even though the root directory I have open in VSCode is parent directory two levels above the Cargo.toml file of each of the multiple projects

bors added a commit that referenced this issue Mar 28, 2023
feat: Pop a notification prompting the user to add a Cargo.toml of unlinked file to the linkedProjects

cc #13226 #9661
@shepazon
Copy link

shepazon commented Jan 5, 2024

Being able co configure the depth of auto-discovery would be so very helpful. Having to configure my VS Code to include specific directories for all my projects sounds like tedium. That would be a lot of unnecessary manual setting maintenance.

Wilfred added a commit to Wilfred/rust-analyzer that referenced this issue Jun 6, 2024
Currently, rust-analyzer highlights the entire region when a `cfg` is
inactive (e.g. `#[cfg(windows)]` on a Linux machine). However,
unlinked files only highlight the first three characters of the file.

This was introduced in rust-lang#8444, but users have repeatedly found
themselves with no rust-analyzer support for a file and unsure
why (see e.g. rust-lang#13226 and the intentionally prominent pop-up added in
PR rust-lang#14366).

(Anecdotally, we see this issue bite our users regularly, particularly
people new to Rust.)

Instead, highlight the entire inactive file, but mark it as all as
unused. This allows users to hover and run the quickfix from any line.

Whilst this is marginally more prominent, it's less invasive than a
pop-up, and users do want to know why they're getting no rust-analyzer
support in certain files.
bors added a commit that referenced this issue Jun 6, 2024
fix: Highlight unlinked files consistently with inactive files

Currently, rust-analyzer highlights the entire region when a `cfg` is inactive (e.g. `#[cfg(windows)]` on a Linux machine). However, unlinked files only highlight the first three characters of the file.

This was introduced in #8444, but users have repeatedly found themselves with no rust-analyzer support for a file and unsure why (see e.g. #13226 and the intentionally prominent pop-up added in PR #14366).

(Anecdotally, we see this issue bite our users regularly, particularly people new to Rust.)

Instead, highlight the entire inactive file, but mark it as all as unused. This allows users to hover and run the quickfix from any line.

Whilst this is marginally more prominent, it's less invasive than a pop-up, and users do want to know why they're getting no rust-analyzer support in certain files.

Before (note the subtle grey underline is only at the beginning of the first line):

![Screenshot 2024-06-05 at 5 41 17 PM](https://github.com/rust-lang/rust-analyzer/assets/70800/96f5d778-612e-4838-876d-35d9647fe2aa)

After (user can hover and fix from any line):

![Screenshot 2024-06-05 at 5 42 13 PM](https://github.com/rust-lang/rust-analyzer/assets/70800/6af90b79-018c-42b9-b3c5-f497de2ccbff)
@supamongkonR
Copy link

For anyone who still can't solve this problem or new joiner of rust that facing this problem when you working on sub directory like this.

for example

/project
├── backEnd
│ └── src
│ └── Cargo.toml
├── frontEnd
│ └── src/app

you can solve this issue by going to setting.json in VS code or click setting in VS code then search rust then click Edit in setting.json

you need to specific path to you Catgo.toml of the project that you working on by adding

 "rust-analyzer.linkedProjects": [
    "/home/user/project/backEnd/Cargo.toml"
  ],

then it should be work.

I hope this one can help rust-analyzer problem and enjoy of develop thing in rust.
ferris_happy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rust-project rust-project.json related issues C-enhancement Category: enhancement
Projects
None yet
Development

No branches or pull requests