[libcxx-dev] Testing std::filesystem on Windows

[Martin Storsjö via libcxx-dev]

On Mon, 19 Oct 2020, Stephan T. Lavavej wrote:

> Our own filesystem tests (Apache-2.0 WITH LLVM-exception, as usual) are 
> here: 
> https://github.com/microsoft/STL/blob/39eb812426167fc7955005b53b28d696c50e8b61/tests/std/tests/P0218R1_filesystem/test.cpp 
> I don't immediately know how we could contribute this to libcxx given 
> the difference in our test strategies (where libcxx typically has one 
> test per section and MSVC typically has one test per paper, leading to 
> large test cases like this one), but perhaps the various parts testing 
> Windows paths could be useful to you?

Thanks for the pointer here - those tests did point out a handful of 
windows specific behaviours that I had missed by just testing my 
implementation against libc++'s tests (with more yet-unmerged patches to 
make those tests work with the STL).

Also the test, being just one single file, had the upside of being much 
faster to compile and test than libc++'s, split up over more files...

At this point, I have an implementation for windows that passes libc++'s 
tests to the same degree as the STL (i.e. with some test references 
changed to what's expected for windows, and some bits disabled), and 
passes most of the STL's filesystem test as well.

I'll start upstreaming the implementation soon. Unfortunately, it's a 
pretty large change. I have it split up over a number of patches, split by 
topic/area to keep them on-topic. As the libc++ filesystem implementation 
doesn't compile for windows as-is, it doesn't actually compile 
successfully until after the first 20 or so patches.

(From the get-go it wouldn't take that many tweaks to make it compile, but 
the path class is supposed to be based on wchar_t, and switching that over 
breaks almost all of the existing code in src/filesystem/operations.cpp. 
So the following patches fix that up to use corresponding filesystem 
functions that take wchar_t, and in many cases, using windows native 
functions instead of posix-lookalike functions that don't behave exactly 
as needed in many cases, especially relating to symlinks.)

// Martin