Consider not using canonicalizePath #67
Description
There is a long-standing issue in VS Code that causes diagnostic reports (such as via haskell-lsp) to be treated as if they apply to a different file on case-insensitive file systems, if Code was opened in a non-canonically-cased path.
For example:
cd c:\users\myself\projects\my-project
code .
According to the HIE log, haskell-lsp was initialized in the directory
c:\users\myself\documents\projects\my-project
and HaRe is sending back messages for the URI
file:///C%3A/Users/myself/Documents/Projects/my-project/Thingy.hs.
The associated diagnostics (squiggles etc.) do not appear in the expected editor window; instead, VS Code reports a problem in what appears to be a distinct file, at the canonicalized path, which by this point is out of sync with my original file (since it lacks changes that had not yet been saved to disk).
There are a couple of workarounds for this:
- Only open Code using the context menu in Explorer, so that it isn't loaded in a non-canonically-cased directory
- Use tab completion in PowerShell (or whatever) when running
codeon the command line, which automatically corrects casing
This still leaves the issue as a gotcha if the user happens to overlook an incorrectly-cased directory at the command prompt. Given that the VS Code issue has been open for a year and a half, with several apparently unsuccessful attempts at resolving it, I wonder if it would be easier to fix it here by avoiding changing the casing on the path after refactoring.
Unfortunately I don't know enough about how HaRe works to know if that would break other stuff. Does anyone know if it is sufficient to call System.Directory.makeAbsolute, or is the canonicalization necessary for other reasons so we cannot address it here?
Relevant commits include