Fix percent-encoded drive letter colon (%3A) in Windows file URIs

[ActaVerba]

Summary

Some LSP clients send file URIs with the drive letter colon percent-encoded as %3A (e.g., file:///c%3A/Users/...). The existing _dosPathRegex in getFilePath() only matches literal colons, causing it to fail to strip the leading slash and decode the path correctly on Windows.

This results in invalid file paths that break path resolution, particularly when using --threads for parallel type checking (where URIs are serialized between worker threads).

Changes

• Updated _dosPathRegex to also match %3A/%3a after the drive letter: /^\/[a-zA-Z](?::|%3[aA])\//
• Added decode step to convert %3A/%3a back to : after stripping the leading slash

Test

Before fix:

• file:///c%3A/Users/project/file.py → /c%3A/Users/project/file.py (broken path)

After fix:

• file:///c%3A/Users/project/file.py → c:/Users/project/file.py (correct path)

Verified with pyright --threads auto on a real Windows project — paths resolve correctly.

[rchiodo]

Can you add some unit tests for your scenario to make sure this doesn't regress again? There should be a set of unit tests for URIs.

[edvilme]

I wonder if there are other characters being encoded the same way, and if an approach other than string replacement would exist

[rchiodo]

I wonder if there are other characters being encoded the same way, and if an approach other than string replacement would exist

This is the only character we're looking for. It's specifically for finding drives on Windows. I suppose it's possible it could be translated a different way, but I've not seen that before.