Multi-root workspace in vscode

[iamshreeram]

This is how my vscode workspace appears:

~
 | /.cargo/
 | /.cabal/
 | /.nvm/
 | .bash_profile
 | .bashrc
 | /project/
 |  | /Clojure/
 |  |  | /allmycljprojects 
 |  | /Shell/
 |  |  | /allmybashprojects 
 |  | /rust/
 |  |  | /proj
 |  |  |  | /project-1
 |  |  |    | /src
 |  |  |       | main.rs
 |  |  |    | Cargo.toml
 |  |  |    | Cargo.lock
 |  |  |  | /project-2
 |  |  |    | /src
 |  |  |       | lib.rs
 |  |  |    | Cargo.toml
 |  |  |    | Cargo.lock
 |  |  |  | /project-3
 |  |  |    | /src
 |  |  |       | main.rs
 |  |  |    | Cargo.toml
 |  |  |    | Cargo.lock
 |  |  | /wasm
 |  |  |  | http-server
 |  |  |    | /src
 |  |  |       | main.rs
 |  |  |    | Cargo.toml
 |  |  |    | Cargo.lock
 |  |  | /ml
 |  |  |  | /sklearn-rs
 |  |  |    | /src
 |  |  |       | main.rs
 |  |  |    | Cargo.toml
 |  |  |    | Cargo.lock
 |  | /haskell/
 |  |  | /allmyhaskellprojects
 |  | /python/
 |  |  | /allmypythonprojects 
 |  | /go/
 |  |  | /bin
 |  |  | /pkg
 |  |  | /src
 |  |  |  | /github.com
 |  |  |    | /tarekbadrshalaan/
 |  |  |    | /elastic  
 |  |  |  | /gecgithub.jparrowsec.cn
 |  |  |    | /ers 
 |  |  |      | /ocf-gql
 |  |  |         | go.mod
 |  |  |         | go.lock
 |  |  |         | cmd
 |  |  |      | /dummy-app
 |  |  |         | go.mod 
 |  |  |  | /gitlab.com
 |  |  |  | /golang.org
 |  |  |  | /gopkg.in
 |  | /scala/
 |  |  | /allmyscalaprojects
 |  | /node/
 |  |  | /allmynodeprojects

I used rust-analyzer.linkedProjects in settings.json to enable auto-completion with RALS (Rust Analyzer Language Server). It worked well, but I had to modify the settings whenever I created a new cargo project.

To address this, I started updating rust's workspace.members manually with all my Cargo.toml paths to track them. It is manageable but still requires manual effort.

1. Is this a recommended practice?
2. Is there a way to automate this process and allow vscode RALS to track all Cargo.toml files within a specific folder on its own, and by eliminating the need for manual updates?

[iamshreeram]

• @bjorn3 , @matklad for review.

[alibektas]

For a multi-language project it is recommended to use linkedProjects. An automation is not amongst our plans as we leave the decision to the user which projects they want rust-analyzer to interact with ( and there are technical reasons such as project discovery in nested projects) . I guess you could use a virtual workspace and link to its Cargo.toml

As to the reviewers it would be very kind of you to choose more active maintainers. As a matter of fact somebody will eventually answer your questions so you don't really need to ping anyone.

EDIT : The author has already mentioned, that they use workspace.members, so my recommendation had already been considered by them.

[iamshreeram]

@alibektas , Thank you for your response. Should we utilize both linkedProjects and workspace.members, or is using either one of them sufficient? Currently, I have included all my Cargo.toml files in the workspace.members and referenced them in linkedProjects. Auto-completion works but with the below Flycheck errors in RALS logs (see below) when I save the file -

[ERROR flycheck] Flycheck failed to run the following command: CommandHandle { program: "cargo", arguments: ["check", "--workspace", "--message-format=json-diagnostic-rendered-ansi", "--manifest-path", "/Users/home/ram/project/rust/domfind/Cargo.toml", "--all-targets"], current_dir: Some("/Users/home/ram/project/rust/domfind") }

[alibektas]

You see there is not a single way to answer your question. Normally if you can open your rust workspace as the $ROOT_DIR in your editor of choice, rust-analyzer should handle the rest and discover the projects for you. If you think that your rust projects should be completely isolated from one another then you should really use linkedProjects but this should tell you also that you could have actually opened your editor on one of your projects instead of an ancestor directory. If your projects are related and maintained together then you should gather them under the same workspace.

[alibektas]

As to the error : What is the output of cargo check when executed under the domfind project ?

[iamshreeram]

Output of cargo check under domfind

error: current package believes it's in a workspace when it's not:
current:   /Users/home/ram/project/rust/domfind/Cargo.toml
workspace: /Users/home/ram/project/rust/Cargo.toml

this may be fixable by adding `domfind` to the `workspace.members` array of the manifest located at: /Users/home/ram/project/rust/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.

[alibektas]

Output of cargo check under domfind

error: current package believes it's in a workspace when it's not:
current:   /Users/home/ram/project/rust/domfind/Cargo.toml
workspace: /Users/home/ram/project/rust/Cargo.toml

this may be fixable by adding `domfind` to the `workspace.members` array of the manifest located at: /Users/home/ram/project/rust/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.

Without having seen how your Cargo.toml looks I can't really give an answer but the error should be self-explanatory. The error from rust-analyzer is one that stems from this cargo error. As such, I believe this issue can be closed if that's OK with you too.

[Veykril]

Note that you can have a workspace local vscode settings.json file that specifiy the linkedProjects, instead of putting that globally. Otherwise this will have to wait on the rust-analyzer.toml. Also, you only need to specify the top most cargo workspaces (any members /dependencies of those workspaces will be automatically considered by r-a)