[llvm-bugs] [Bug 38419] std::filesystem::path::native() should return an std::wstring on Windows

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=38419

Martin Storsjö <martin at martin.st> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #2 from Martin Storsjö <martin at martin.st> ---
This should all be fixed now, by e.g. e83e0cac041bc071301f8399bb5c32b2529fc83f
([libcxx] Make filesystem::path::value_type wchar_t on windows) and
f4f5fb915104887fefa602cfcbd1d4fc8447d46b ([libcxx] Make generic_*string return
paths with forward slashes on windows).

Also note that before, while you could observe these incorrect behaviours in
the <filesystem> header, it wasn't even possible to build libc++ with
filesystem enabled for windows, until around
cdc60a3b9aa523b49329a7a5e4c1774d3b9e3db9. Before that, you could do trivial
header-only operations, but as soon as you'd try to do something that requires
linking against the lib, it'd fail. (Also, after
933518fff82c8f39626bbcca81adc516483a9651, trying to use header-only bits of
<filesystem> will fail if the lib was built with filesystem disabled.)

Now at this point, the filesystem code can be built for windows, but it's only
enabled by default for mingw targets. In MSVC configurations, you'll still run
into a missing runtime helper for __int128, see https://reviews.llvm.org/D91139
and https://reviews.llvm.org/D91413 for various ways of getting around that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210303/2be59d10/attachment-0001.html>