You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I know Url is just reexported by lsp-types but I think the issue is more relevant to this crate than to the url crate (since it affects this crate's users), but I'll be happy to open an issue there too if this is not the right place.
I'm working on a language server project and with an extension for visual stdio code and ran into the following issue:
I store my files in a DashMap<Url, MyFile> since most of the time the lookups are done based on requests and notifications from the client, and converting each Url to a PathBuf would be quite wasteful. I also scan the opened folder (based on RootUri) on startup to construct the whole database of files. When scanning I convert the RootUri to a PathBuf, collect the files from the directory and convert each PathBuf to an Url to insert it in the map (I think this is acceptable since it's only done once).
But when I tried to check if a file that is being opened (didOpen) is in the DashMap after running the initial scanning, the lookup failed.
The reason is the visual studio code sends the uri with a %3A instead of : after the disk letter on windows. Link to playground.
use url;#[cfg(test)]mod test {#[test]fntest(){let url_from_vscode = url::Url::parse("file:///C%3A/test.txt").unwrap();let path = url_from_vscode.to_file_path().unwrap();let url_from_path = url::Url::from_file_path(&path).unwrap();println!("{:?}", &url_from_vscode);println!("{:?}", &path);println!("{:?}", &url_from_path);assert!(url_from_vscode == url_from_path);}}
Thanks in advance for the help and keep up the great work.
The text was updated successfully, but these errors were encountered:
Is there something actionable on the crate side? You should be able to normalize the Url before using it as a key for the map. Maybe we could do this when deserializing but that seems potentially surprising also.
According to this issue, they don't plan on providing canonicalization.
The other option seems to be url_normalizer, but I haven't tested it.
The simplest thing your crate could do is have a warning in the docs that url normalization is not handled and urls coming from clients might not match urls that the Url produces (using from_file_path()).
The other option would be to wrap Url and provide an Eq implementationt that normalizes both urls before checking.
I know
Url
is just reexported bylsp-types
but I think the issue is more relevant to this crate than to theurl
crate (since it affects this crate's users), but I'll be happy to open an issue there too if this is not the right place.I'm working on a language server project and with an extension for visual stdio code and ran into the following issue:
I store my files in a
DashMap<Url, MyFile>
since most of the time the lookups are done based on requests and notifications from the client, and converting eachUrl
to aPathBuf
would be quite wasteful. I also scan the opened folder (based onRootUri
) on startup to construct the whole database of files. When scanning I convert theRootUri
to aPathBuf
, collect the files from the directory and convert eachPathBuf
to anUrl
to insert it in the map (I think this is acceptable since it's only done once).But when I tried to check if a file that is being opened (
didOpen
) is in theDashMap
after running the initial scanning, the lookup failed.The reason is the visual studio code sends the uri with a
%3A
instead of:
after the disk letter on windows. Link to playground.Thanks in advance for the help and keep up the great work.
The text was updated successfully, but these errors were encountered: