-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
failed to discover workspace when running as a live share session guest #8844
Comments
From the windows side, the path is an arbitrary drive letter. |
This isn't going to work. Rust-analyzer needs to be able to read files outside of the control of the editor. This is necessary to for example run |
That's weird, because the error happens on the visitor side, and the windows visitor gets a drive letter in the path even when the host is running linux, and vice-versa |
rust-analyzer is running on both the host and visitor already. Are you saying there is/should be a way to pass the host's r-a to the visitor? |
Either the host's r-a needs to be passed through to the visitor or live share needs to report the actual location of the local mount of the project instead of |
Live Share only works with rust-analyzer when using Microsoft's official VS Code builds, it does not work with OSS builds or VS Codium. rust-analyzer does not have to be installed or enabled locally for this to work. If rust-analyzer is enabled locally, then you get the error popup (which can be ignored). We should add this to the manual, and ideally figure out a way to not activate the local extension when running in a Live Share session. |
yes, this bug would not be possible if I wasn't using the official build |
…-schievink fix: Avoid error popup when using in Live Share cc #8844 Not sure if there's a better way to do this, feedback appreciated!
When running as a guest in a live share session, rust-analyzer shows an error popup that it "failed to discover workspace". In the debug output, there is this message:
The full trace log is here: rust-analyzer_trace.log
Versions:
The same thing happened (with a different path in the error) going the other way, with the windows guest on linux host session.
The text was updated successfully, but these errors were encountered: