Skip to content
This repository was archived by the owner on Dec 8, 2020. It is now read-only.

Support cargo workspaces #158

Open
John0x opened this issue Mar 25, 2017 · 16 comments
Open

Support cargo workspaces #158

John0x opened this issue Mar 25, 2017 · 16 comments

Comments

@John0x
Copy link

John0x commented Mar 25, 2017

Currently vscode-rust does not support cargo workspaces properly.
Have you yet thought about adding support for it?

@KalitaAlexey
Copy link
Member

Hello.
I haven't thought about it.
And I have no time for that now.
I would be glad to discuss it here and accept your a PR.

@icorderi
Copy link

I'm not sure if this are the issues @John0x was referring to in workspaces.

Environment

I just swapped to RLS-mode and I run into a few workspace related issues:

My workspace looks like this (it is NOT an rust-only workspace):

repo/
  |- some-non-rust-stuff
  |- ...
  |- rust/
      |- rust-project-a/
          |- Cargo.toml
      |- rust-project-b/
          |- Cargo.toml
      |- Cargo.toml (virtual) // root of the rust workspace

Behavior

case 1) When I'm editing some rust file in rust-project-a I get the following error:

thread '' panicked at 'could not find root manifest: could not find Cargo.toml in /Users/xxx/git/repo or any parent directory', src/libcore/result.rs:859

case 2) If I switch to repo/rust as the root of my vscode workspace I get the following error:

thread '' panicked at 'could not run cargo: manifest path /Users/xxx/git/repo/rust/Cargo.toml is a virtual manifest, but this command requires running against an actual package in this workspace', src/libcore/result.rs:859

case 3) If I switch to repo/rust/rust-project-a as the root of my vscode workspace then it works.


Case 1 and case 2 seem to be triggering the same bug. Case 3 shows the code is fine once it locates the correct Cargo.toml.

The Cargo.toml associated with a given *.rs should be the first Cargo.toml from that file up, NOT from the root of the workspace.

We had a similar issue a year or so ago with the cargo build searching from the workspace root instead of the current file.

@John0x
Copy link
Author

John0x commented May 15, 2017

@icorderi yeah, that is the same issue I have.
Would be awesome if it could be fixed :)
I'd do it myself, though I sadly don't have the time right now :/

@nox
Copy link

nox commented Jun 13, 2017

Is there any way we can help on this? The other Rust VSCode plugin doesn't seem to suffer from the same issue.

@oherrala
Copy link

@icorderi there is also issue about this panic in rls repo: rust-lang/rls#263

@icorderi
Copy link

Thanks @oherrala, yea, people seem to be hitting this a lot.
@nox, you don't see it on the old rusty-code because it was fixed for workspaces when workspaces came out.
"Similar" work needs to be done for the RLS integration.
I did some digging on where I think the problem is and what needs to get done on issue #156.

I think we are short on manpower, @KalitaAlexey might be a bit overwhelmed, I don't know who else is actively maintaining this with him.

So if you can get a PR that would help.

@KalitaAlexey, do you think my guesswork on #156 is accurate enough for someone to go dig further and try to fix it?

@KalitaAlexey
Copy link
Member

@icorderi,
The line shows that the extension can specify working directory on initialization.
The first thing to do is to pass the current working directory to the RLS initialization.
The first problem pops up is that there will be inconsistency between Cargo and RLS:
Cargo has special algorithm of finding the current working directory. The current working directory is determined for each command invocation (it allows us to have multiple projects in the workspace (I'm talking about vscode workspace).
On the other hand if we set RLS working directory to some directory and start working with some other directory, then Cargo will build the new directory, but RLS will show diagnostics for the old directory.
The easiest solution is to restart RLS when the current working directory is changed, but I'm doubt developers would be glad if they switched to other project for one second and the whole analysis of their previous huge project will be erased.

@TyOverby
Copy link

RLS now supports "Workspace Mode": rust-lang/rls#409

@clouds56
Copy link

clouds56 commented Mar 4, 2019

What's the state now?

@nox
Copy link

nox commented Apr 11, 2019

Any news on this?

@nox
Copy link

nox commented May 7, 2019

Could anyone familiar with the project give directions as to how to implement that? It's a damn big paper cut to not be able to use RLS in Code with any project using workspaces.

@oherrala
Copy link

oherrala commented May 7, 2019

@nox is there some specific problem you are encountering? I have been happily using workspaces in vscode-rust for quite some time already.

@nox
Copy link

nox commented May 7, 2019

These days I work on victor, and if I open the project root in Code and, say, introduce a syntax error in a file from the victor crate in that workspace, RLS doesn't complain about anything, which lets me think that it's not compiling that crate at all. Am I missing something?

@nox
Copy link

nox commented May 7, 2019

Also, when opening the project root, rustfmt integration seems to be broken:

[Error - 10:22:08 AM] Request textDocument/formatting failed.
  Message: Reformat failed to complete successfully
  Code: -32603

@nox
Copy link

nox commented May 9, 2019

Oh I guess the first issue is #287.

@nox
Copy link

nox commented May 9, 2019

Well, seems like adding a default-members key with the crates I care about in the top-level Cargo manifest fixed that issue. I still have a problem with the formatting command though.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants