Normalize file paths before converting to Uri's

[jneira]

• In hie we've detected some VFS missings cause the key used to lookup the map only differed in the drive letter case: HIE (commit 7c206d) crashes unexpectedly mpickering/haskell-ide-engine#64 (comment)
• The standard somewhat recommends make the drive letter upper case to avoid those issues: https://tools.ietf.org/html/rfc8089#page-13
• The code to normalize the filepaths before converting in URI is similar to the function System.FilePath.normalise (including make the driver letter upper case) but when i tried to use it some test cases failed so i am not sure if its use was avoided by design.

[jneira]

I am afraid (as @mpickering suspected) that this pr dont ensure all Normalized Uri have the win drive letter upper case.
I wrongly supposed the only way to get it would be FilePath -> Uri -> Normalized Uri but Uri has an Aeson instance (and a Read one!) and it can be produced directly from json (that may have uris with the drive letter lower case)
(UPDATE: he, you can even use directly the Uri constructor, which is public)

So the only way to ensure is to move the code doing the upper case to toNormalizedUri

[jneira]

I am not sure if it is the best way to do it.
filepathToUri main work is to prepare FilePath to convert it to Uri (except making the driver letter upper case)

[jneira]

I've found that fixing the keys of the VFS with this change makes hlint suggestions appear again in vscode:

So it would fix haskell/haskell-ide-engine#1441 and other related issues in hie.

[jneira]

So, you think that actual impl can be acceptable @alanz @cocreature ?
Another alternative ones could be:

• Move the normalization of windows driver to toNormalizeUri, converting file uris to paths and make the upper case directly instead use filePathToUri
• A more radical one: use System.FilePath.normalise (that already makes upper case the driver letter) and require paths to be absolute, cause normalise remove bogus .. Uri's only support . for absolute paths, the fact that you can create uris using . at first path component is coincidental as this test case demonstrates:

https://github.com/alanz/haskell-lsp/blob/d76f0cd94e73c2196954c909eec7b6f4443fe668/test/URIFilePathSpec.hs#L77-L83

But this would be a breaking change

[alanz]

If I recall correctly, fairly early on in HIE development we decided to always use absolute paths, and have nothing relative to cwd, as it is not something you can always rely on, especially if there are multiple packages being served by the same hie server. The project root supplied by the client is used to convert to and from absolute paths, if needed.

And for an index into the VFS, an absolute, normalized path makes sense.

[jneira]

Ok, i've changed the code to use FP.normalise so:

• The driver letter is converted to upper case
• The current dir paths are removed

So the resultants uris are more likely to be unique than before

I've updated the tests to cover the above changes and to prove that conversions works with paths using unicode chars.

However i've not add any restriction over relative paths. It would suppose:

• Throw a runtime error in the actual filePathToUri
• Or change its signature to FilePath -> Maybe Uri or FilePath -> Either ParseUriError Uri

I think it should belong to another pr cause the objective of this one would be fix uniqueness of uris as map keys.

So for me this could be merged.

[jneira]

The tests with unicode paths are failing for some environments (or seeds?), investigating

[jneira]

It seems we hit this issue with unicode generation so i've applied the same patch than this pr

[alanz]

@jneira If you are happy with this it can merge.

[jneira]

@alanz yeah i think it could be merged