Consider not using `canonicalizePath`

[johnsonwj]

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 code on 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

• 3cdf330 - ghc-mod no longer changes to the cradle dir.
• 084e89b - Canonicalize file paths so command line file paths match loaded module graph

[johnsonwj]

Another option would be to "normalize" the URI in a slightly different sense: when the diagnostics are published in HIE, we could replace the base of the URI with HIE's project root, which would hopefully induce the correct casing.

[alanz]

I am happy to use makeAbsolute instead of canonicalize, I must admit I am not sure what the differences are.

[johnsonwj]

Cool! I will try it out and PR it if it works :)

It seems like canonicalizePath does a few things in addition to fixing the casing on Windows:

• Removes . and .. from a path which is otherwise absolute: /home/willj/projects/project-1/../project-2/././././Thingy.hs
  • actually it looks like /./ is removed in both cases due to normalise, and canonicalizePath only removes .. indirections
• Dereferences symlinks
• Drops trailing path separator if the path is a directory (presumably this case doesn't apply to HaRe)

I will also try running code with a path that contains the first two cases to see what happens!

[alanz]

@johnsonwj See my ghc-8.4 branch, I made the change. I am contemplating passing the ghc-mod Uri in directly

[johnsonwj]

Ah, awesome! I am away from my Windows machine right now but will try it out later. In the meantime I can try it out on osx.