WSL support

[yisonPylkita]

To resolve all concerns with WSL (#160, #247, #144 ) and to fix my half-baked implementation GH-161 I have created this PR. It should fix all of the problems with running this extension via WSL.

This is still WIP. The only missing thing is mapping filesystem paths from vscode language client (windows) to rls (wsl)

Example:
I have simple rust application kudu. Lets run vscode on this application project.
Initialization, rls detection, (installation if needed) and so on works without problems. Hard part begins when rls tries to look for Cargo.toml.

I got error

Error reading manifest path: ErrorMessage { msg: "could not find `Cargo.toml` in `/c:/H_DEV/kudu` or any parent directory" }

It seems that to make this whole WSL thing working we need to make rls aware of wsl. Simplest way to fix it should be by introducing a filesystem paths mapping mechanism. So path c:/H_DEV/kudu should be mapped to /mnt/c/H_DEV/kudu.

@Xanewok any ideas how to implement paths mapping in rls ?

[nrc]

It seems that to make this whole WSL thing working we need to make rls aware of wsl. Simplest way to fix it should be by introducing a filesystem paths mapping mechanism. So path c:/H_DEV/kudu should be mapped to /mnt/c/H_DEV/kudu

Where do these paths come from? Are they the ones from the compiler? I.e., the filenames in spans? Or is it something more specific to the RLS?

[yisonPylkita]

These paths comes from vs-code but an extension has no way to modify them.
I will clarify myself - they comes from vs-code language server.

I suspect that first problematic path comes from initialize request - https://microsoft.github.io/language-server-protocol/specification#initialize

[nrc]

So the file URIs in the ranges from the client?

[bharrisau]

Inside the WSL environment there is the /bin/wslpath helper that will map from Windows paths to Linux paths. But there doesn't seem to be a good place to hook that path translation in.

[reminjp]

So using wslpath like this?

C:\>wsl.exe wslpath 'c:/H_DEV/kudu'
/mnt/c/H_DEV/kudu

C:\>wsl
remin@laptop:/mnt/c$ wsl.exe wslpath 'c:/H_DEV/kudu'
/mnt/c/H_DEV/kudu

Of course, we do not have to call wsl.exe in WSL.

remin@laptop:/mnt/c$ wslpath 'c:/H_DEV/kudu'
/mnt/c/H_DEV/kudu

[bharrisau]

Yes, it should also work in reverse with the `-w` flag (from memory). Better than hard coding a regexp or something as wslpath looks at the wsl configuration to do the mapping correctly (in case you use a non standard mount point).

…

On Fri., 14 Dec. 2018, 3:10 am remin, ***@***.***> wrote: So using wslpath like this? C:\>wsl.exe wslpath 'c:/H_DEV/kudu' /mnt/c/H_DEV/kudu C:\>wsl ***@***.***:/mnt/c$ wsl.exe wslpath 'c:/H_DEV/kudu' /mnt/c/H_DEV/kudu Of course, we do not have to call wsl.exe in WSL. ***@***.***:/mnt/c$ wslpath 'c:/H_DEV/kudu' /mnt/c/H_DEV/kudu — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#335 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHUlpu7oKC9xOR0VkAXC6j9yN3dN18lks5u4qYMgaJpZM4Uj4No> .

[tim-stasse]

So what needs to be done to get this across the line? I'd love to have this working, but this PR has been open since June...

[bharrisau]

It seems like the communication is between VSCode and RLS(in WSL) directly. I can't see anywhere that the rls-vcode extension is able to map the paths before they are sent to RLS. That is the main part missing from this PR. If someone can point me in the right direction I can take a look. All the other language extensions that handle WSL (that I've looked into anyway) are using a custom protocol and aren't using the LanguageServerClient stuff.

This PR currently just allows rustup et.al. to be used inside WSL - I'm doing the same thing by just using a rustup.bat file and setting the rustupPath config to point to it. Same thing.

[yisonPylkita]

All the other language extensions that handle WSL (that I've looked into anyway) are using a custom protocol and aren't using the LanguageServerClient stuff

This is interesting. I didn't had enough time to look into different vs-code plugins with WSL support.
Yet I think that replacing vs-code protocol just for the sake of this functionality is too much.

Originally I came up with an idea to run RLS (inside WSL) with an command line option like --wsl-mapping and to make RLS translate paths from Windows to WSL paths (So C:\\H_DEV\kudu would become /mnt/c/H_DEV/kudu)

From my research half a year ago you cannot change paths that are being sent between rls-vscode and RLS. This mapping have to be done in RLS

My rust skills are too low to do this so I gave up on this

[yisonPylkita]

Work on this feature moved to #488.
@hzahradnik found a way to map paths between WSL and Windows.

[dtysky]

Any update?

[yisonPylkita]

@dtysky Pretty much done. Functionality is implemented yet it still require some tests.

Do you mind to be a tester ? (Windows 10 required)

[dtysky]

@dtysky Pretty much done. Functionality is implemented yet it still require some tests.

Do you mind to be a tester ? (Windows 10 required)

My pleasure, so what should I do?

[Xanewok]

@dtysky To run the extension from source (and this PR branch) please follow the steps in contributing.md.

I don't develop on Windows, but I believe the use case here is that you want to install and use your Rust toolchain from inside the Windows Subsystem for Linux (WSL) inside a Visual Studio Code instance that's installed in and managed by Windows.

To verify the fix, I believe it's enough to simply create a dummy project with cargo new my-lib, initialize VSCode inside and check if you get any completion or IDE features whatsoever.

@yisonPylkita is the above correct and/or did I miss anything?

Also, I'm going to close this PR since the work on this moved to #488, please move the discussion there.

[yisonPylkita]

@Xanewok You are right. These are the basic steps to check this feature.

I wrote a little tutorial how to test this extension #488 (comment). Hope it will be helpful for anybody who wants to test this feature.