fix(windows): invalid directory name due to leading slash

[vonPB]

After updating ra-mulitplex on my windows machine it stopped working.

Caused by:
    0: spawning langauge server: server="rust-analyzer", args=[], cwd="/c:/Users/<USERNAME>/source/repos/XYZ",...
1: The directory name is invalid. (os error 267)"

Removing the / in front of the drive letter (e.g., converting /c:/ to c:/) fixed the issue for me.

Note: I have not performed testing beyond confirming that it now works for my environment.

[pr2502]

hi! before we merge an ad-hoc fix like this, i'd be really interested in how that leading / even got there. uriparse function should've removed the leading file:// protocol type and separators and it seems weird rust-analyzer would send file:/// on windows, maybe it's a bug in our lsp proxy which we should fix instead.

could you please run ra-multiplex (with or without this patch, that doesn't matter) with log_filters = "debug" in config and check what gets logged on src/client.rs:63?

[vonPB]

Hey, the options looks correct.

DEBUG client{client_id=0}: lspmux initialization options={"version":"1","method":"connect","server":"rust-analyzer","args":[],"cwd":"C:\\Users\\Philipp\\source\\repos\\<MY_REPO>"}

But the cwd is not the workspaceFolder :)

When printing req.params from

ra-multiplex/src/client.rs

Line 44 in 586f8c9

let mut init_params = serde_json::from_value::<InitializeParams>(req.params.clone())

we can observe the following in the workspaceFolders:

"workspaceFolders": Array [
  Object {
      "name": String("c:\\Users\\Philipp\\source\\repos\\<MY_REPO>"),
      "uri": String("file:///c:/Users/Philipp/source/repos/<MY_REPO>")
  }
]}

same format of the URI in the debug log for file notifications:

DEBUG client{client_id=0}: last client closed file notif={"jsonrpc":"2.0","method":"textDocument/didClose","params":{"textDocument":{"uri":"file:///C:/Users/Philipp/source/repos/<MY_REPO>/src-tauri/src/utility/daqmx/mod.rs"}}}  

Directly logging the lsp message here as a string also shows that the uri is indeed returned with /// from rust analyzer.

ra-multiplex/src/lsp/transport.rs

Line 133 in 586f8c9

let bytes = self.buffer.as_slice();

It seems that the /// is a correct URI
https://en.wikipedia.org/wiki/File_URI_scheme#:~:text=file%3A///c%3A/path/to/the%2520file.txt

I think there is no way around the additional check when dealing with windows native paths :/

[pr2502]

Aha, playing with some inputs it appears uriparse just doesn't understand the special meaning of C:/ and instead parses it as the first segment of an absolute path and then the implementation of Display prefixes it with / unconditionally. https://docs.rs/uriparse/latest/src/uriparse/path.rs.html#578-592.

[src/main.rs:17:5] URI::try_from("file:///c:/foo/bar.txt").unwrap().into_parts() = (
    File,
    Some(
        Authority {
            host: RegisteredName(
                RegisteredName {
                    normalized: true,
                    registered_name: "",
                },
            ),
            password: None,
            port: None,
            username: None,
        },
    ),
    Path {
        absolute: true,
        double_dot_segment_count: 0,
        leading_double_dot_segment_count: 0,
        segments: [
            Segment {
                normalized: true,
                segment: "c:",
            },
            Segment {
                normalized: true,
                segment: "foo",
            },
            Segment {
                normalized: true,
                segment: "bar.txt",
            },
        ],
        single_dot_segment_count: 0,
        unnormalized_count: 0,
    },
    None,
    None,
)

So this approach really seems to be the best way to handle this. I hate it :D
And thanks for the links and help with the logs^^

[pr2502]

Thanks!

[vonPB]

Not a fan of the solution as well, but happy to help :)