Non-file URI in LSP response has first letter of path converted to lowercase (starting from Pyright 1.1.351)

[jwortmann]

Describe the bug

I'm using Pyright as an LSP server in Sublime Text. I've noticed that starting with Pyright 1.1.351, the first letter of the path component of a server response is always converted to lowercase. According to the LSP specs, this is allowed for the drive letter (in file: URIs):

Clients and servers should not assume that each other are encoding the same way (for example a client encoding colons in drive letters cannot assume server responses will have encoded colons). The same applies to casing of drive letters - one party should not assume the other party will return paths with drive letters cased the same as itself.

but it can be problematic (and I assume is not allowed) in non-file URIs, where the first character of the path component is not necessarily a drive letter.

Example params of a textDocument/definition request:

{
    "position": {
        "character": 19,
        "line": 26
    },
    "textDocument": {
        "uri": "res://Packages/Default/symbol.py"
    },
    "workDoneToken": "$ublime-work-done-progress-6"
}

Response:

[
    {
        "uri": "res://packages/Default/symbol.py",
        "range": {
            "end": {
                "character": 17,
                "line": 7
            },
            "start": {
                "character": 4,
                "line": 7
            }
        }
    }
]

Here the letter P should not be lowercased, because it is not a drive letter. Pyright version 1.1.350 and earlier did respond with the correct letter casing.

The res: scheme is used by this client for "virtual" files that don't have a path on disk, but are extracted in memory from a .zip file.

VS Code extension or command-line

• Pyright 1.1.351 or newer (also tested with the latest version 1.1.354) used as an LSP server in Sublime Text
• Windows 11

[rchiodo]

This might be a problem in the vscode-uri module. We use it here to get the 'string' value of a URI:

pyright/packages/pyright-internal/src/common/uri/uri.ts

Line 152 in 114817a

const parsed = URI.isUri(uri) ? uri : URI.parse(uri);

[rchiodo]

It's this line here.
https://github.com/microsoft/vscode-uri/blob/6dec22d7dcc6c63c30343d3a8d56050d0078cb6a/src/uri.ts#L627

Not sure why the authority is always lowercased. There's probably a reason for this. Have to do some more digging.

[rchiodo]

Seems this is on purpose and has been in the vscode-uri code since it's inception here:
https://github.com/microsoft/vscode/blame/90eed31518ac40f9b038d85952e6320f79a51dc3/src/vs/base/common/uri.ts#L261

I believe the root cause is that your URI is encoding part of the path as the authority component. It should be like this:

res:/Packages/Default/symbol.py

That won't change the casing of Packages on the way out.

[jwortmann]

Thank you for the quick response, the responsiveness and bug fixing in this project is awesome!

You are right, the URI format used by the client should be as you pointed out. I will try to fix it at the client side.