I introduced the term to normalize paths and urls, which means pretty much replacing \ with / and decoding percent-encoded characters. This is a one-way operation, since I have no idea how the language clients encode the urls and I don't want to care about it if possible.
Handling normalized and client-style urls added quite a bit of complexity since we have to use both of them.
We walk the fs to find and load source code according to glob patterns defined in the config file, however these paths of the rhai files are naturally not percent encoded.
All document uris we receive from the language client are percent encoded, but in most cases they happen to have been already processed by the procedure above, so the safest thing to do is to normalize all urls received by the language client and only store them in the hir that way. Obviously when we forget to do this, things will silently break due to documents being duplicated with the wrong uri or won't be found at all, fun stuff.
Other than this, we also cannot get rid of the encoded uris, because we send requests from the server-side that invloves document uris (such as diagnostics), and we have to make sure that the language client will find the document we are referring to, and the safest way to do is to use the uris as they were sent by the client (although just as I'm writing this, I've just realized that this is not possible for documents that we process ourselves, and right now it seems to work, so at least vscode is not sensitive to percent encoding and this requirement might be unnecessary).
Other than this I implemented processing of a simple Rhai.toml in the workspace root, and also overhauled a bit the way document loading is done.
I introduced the term to
normalize
paths and urls, which means pretty much replacing\
with/
and decoding percent-encoded characters. This is a one-way operation, since I have no idea how the language clients encode the urls and I don't want to care about it if possible.Handling normalized and client-style urls added quite a bit of complexity since we have to use both of them.
We walk the fs to find and load source code according to glob patterns defined in the config file, however these paths of the rhai files are naturally not percent encoded.
All document uris we receive from the language client are percent encoded, but in most cases they happen to have been already processed by the procedure above, so the safest thing to do is to normalize all urls received by the language client and only store them in the hir that way. Obviously when we forget to do this, things will silently break due to documents being duplicated with the wrong uri or won't be found at all, fun stuff.
Other than this, we also cannot get rid of the encoded uris, because we send requests from the server-side that invloves document uris (such as diagnostics), and we have to make sure that the language client will find the document we are referring to, and the safest way to do is to use the uris as they were sent by the client (although just as I'm writing this, I've just realized that this is not possible for documents that we process ourselves, and right now it seems to work, so at least vscode is not sensitive to percent encoding and this requirement might be unnecessary).
Other than this I implemented processing of a simple
Rhai.toml
in the workspace root, and also overhauled a bit the way document loading is done.Closes #60 and closes #39.