Fix file+noindex URI usage on Windows

[jasagredo]

This PR fixes the parsing of URIs for file+noindex repositories when using Windows paths. As suggested by @phadej in #10703 we now use (and specify in the docs) //./C:/... paths on Windows.

QA

In Windows, one can now specify //./ paths in file+noindex repositories. To check, create a simple package, then cabal sdist, move the tar.gz to some directory and in a different project declare the following stanza:

repository my-local-repo
  url: file+noindex:////./C:/path/to/repo

It might still fail because of #9891

---

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!) fixing other tests failures seems like a good enough test for me

[jasagredo]

Notice this was broken on Windows #10095 (comment), see how the paths in the output do not have a C: component, because of what I described in the first code block of #10703

[ulysses4ever]

Thanks! I wonder if we can pull in some of Andrea’s PRs after this fix…

[ulysses4ever]

Perhaps just inline it [asPosixPath]

I'd suggest not to inline it. I'd definitely prefer reading unrelated code that calls a function like that rather than seeing the list comprehension.

[jasagredo]

Thanks for your thorough review @philderbeast !

[philderbeast]

@jasagredo, I checked the haddocks for Cabal-syntax and found a small rendering glitch:

I think this could be fixed with this patch:

$ git diff
diff --git a/Cabal-syntax/src/Distribution/Utils/Path.hs b/Cabal-syntax/src/Distribution/Utils/Path.hs
index fef2fe996..b082c17b5 100644
--- a/Cabal-syntax/src/Distribution/Utils/Path.hs
+++ b/Cabal-syntax/src/Distribution/Utils/Path.hs
@@ -545,7 +545,7 @@ data PkgConf
 
 -- | Sometimes we need to represent a Windows path (that might have been
 -- normalized) as a POSIX path, for example in URIs, as that is what
--- @network-uri@ understands. Furthermore they need to use the @\\.\@ DOS
+-- @network-uri@ understands. Furthermore they need to use the @\\\\.\\@ DOS
 -- device syntax or otherwise the filepath will be unusable.
 --
 -- >>> import Network.URI

[jasagredo]

@philderbeast

Ah yes sounds familiar, see the first argument of https://hackage.haskell.org/package/Win32-2.14.1.0/docs/System-Win32-NamedPipes.html#v:createNamedPipe and the corresponding source code haddocks 😄

[jasagredo]

I got an idea, but I won't be able to test it until tomorrow or maybe next week hence I'm removing the merge label.

My suspicion is that the path /C:/foo.txt if normalized to \C:\foo.txt can work too and we don't need the //./ syntax.

The basis for the suspicion is the NT namespace mentioned here

And if that is the case maybe I was wrong all along when thinking that network-uri fails to process Windows paths properly and file+noindex:///C:/some/path works if normalized.

[jasagredo]

OK I can confirm it does not work and my assumptions were right:

ghci> readFile "\\C:\\foo.txt"
*** Exception: \C:\foo.txt: openFile: invalid argument (Invalid argument)

In PowerShell:

➜ Get-Content \C:\foo.txt
Get-Content: Cannot find drive. A drive with the name '\C' does not exist.

So the GHC documentation that mentions:

The namespaces are:

• file namespace: \\?\
• device namespace: \\.\
• NT namespace: \

Seems wrong, as such an NT namespace does not seem usable.