[PATCH 0/4]: C++ P1423R3 char8_t remediation implementation

[Jonathan Wakely]

On 29/11/19 17:45 +0000, Jonathan Wakely wrote:
>On 15/09/19 15:39 -0400, Tom Honermann wrote:
>>This series of patches provides an implementation of the changes for 
>>C++ proposal P1423R3 [1].
>>
>>These changes do not impact default libstdc++ behavior for C++17 and 
>>earlier; they are only active for C++2a or when the -fchar8_t option 
>>is specified.
>>
>>Tested x86_64-linux.
>>
>>Patch 1: Decouple constraints for u8path from path constructors.
>>Patch 2: Update __cpp_lib_char8_t feature test macro value, add 
>>deleted operators, update u8path.
>>Patch 3: Updates to existing tests.
>>Patch 4: New tests.
>>
>>Tom.
>>
>>[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html
>
>It took a while, but I've committed these four patches, with just some
>minor whitespace changes and changelog tweaks.

Running the new tests revealed a latent bug on Windows, where
experimental::filesystem::u8path(const Source&) assumed the input
was an iterator over a NTCTS. That worked for a const char* but not a
std::string or experimental::string_view.

The attached patch fixes that (and simplifies the #if and if-constexpr
conditions for Windows) but there's a remaining bug. Constructing a
experimental::filesystem::path from a char8_t string doesn't do the
right thing on Windows, so these cases fails:

  fs::path p(u8"\xf0\x9d\x84\x9e");
  VERIFY( p.u8string() == u8"\U0001D11E" );

  p = fs::u8path(u8"\xf0\x9d\x84\x9e");
  VERIFY( p.u8string() == u8"\U0001D11E" );

It works correctly for std::filesystem::path, just not the TS version.

I plan to commit the attached patch after some more testing. I'll
backport something like it too.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 3846 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20191129/6d7375b7/attachment.bin>