Panic with RLS 1.31.0 and latest vscode extension

[olson-dan]

RLS is panicking on 1.31.0 with vscode extension v0.5.1 whenever opening a folder that uses cargo workspaces. Opening any sub-folder works. v0.5.2 looks like it was intended to address this based on the changelog, but I am still getting the issue under that version.

Since RLS and the VSCode extension were updated at around the same time, it's not clear which is causing the issue. However it seems very-specific to vscode. See this issue: rust-lang/rls#1173

[olson-dan]

I downgraded to 0.5.0 using the instructions here and it resolved the issue.

[mwrock]

I am seeing this same behavior with workspaces on v0.5.2.

[LaylBongers]

Same behavior here, it's broken my workflow ever since 0.5.1

[crlf0710]

I did some basic debugging, and found that this is the data rls received:
InitializeParams { process_id: Some(18348), root_path: Some("\ThirdParty\crlf0710\xxx-rs"), root_uri: Some("file:///ThirdParty/crlf0710/xxx-rs"), ... }

I'm windows user, so this path is missing the drive part. I guess that's why rls panicked, though. I'm not sure which part of the code generates these paths, though.

[mwrock]

I'm a windows user too.

[crlf0710]

After a little more debugging, I found that it's this code that causes this problem:
return Object.assign({}, cur_workspace, { uri: vscode_1.Uri.parse(current) });
when current is: l:\ThirdParty\crlf0710\xxx-rs
the result uri is:
{$mid: 1, path: "\ThirdParty\crlf0710\xxx-rs", scheme: "l"}
however what's expected is something like:
{$mid: 1, external: "file:///l%3A/ThirdParty/crlf0710/xxx-rs", fsPath: "l:\ThirdParty\crlf0710\xxx-rs", path: "/l:/ThirdParty/crlf0710/xxx-rs", scheme: "file"}

So, what's the correct way to generate a file scheme uri from filesystem path?

[Xanewok]

Is that still the case in the 0.6.1?

[olson-dan]

I'm on 0.6.1 now, and it appears to be working fine.