Compile failures with char8_t by MSVC under /std:c++latest(C++20) mode

[QuellaZhang]

We've stumbled across some build failures in Boost\libs\config\test after implementing support for char8_t under /std:c++latest in the development version of Visual C++. Could you help look at this? Thanks in advance! Noted that this issue only found when compiles with unreleased vctoolset, that next release of MSVC will have this behavior.

Repro steps:

1. git clone -c core.autocrlf=true --recursive ​https://github.com/boostorg/boost.git D:\Boost\src
2. open a VS 2017 x86 command prompt and browse to D:\Boost\src
3. set CL=/std:c++latest
4. .\bootstrap
5. .\b2 headers variant=release --build-dir=..\out\x86rel address-model=86
6. .\b2 variant=release --build-dir=..\out\x86rel address-model=86
7. .\b2 -j4 variant=release --build-dir=..\out\x86rel libs\config\test

Failures:
config_test.i
D:\Boost\src\libs\config\test\boost_no_unicode_literals.ipp(20): error C2440: 'initializing': cannot convert from 'const char8_t [1]' to 'const char *'
D:\Boost\src\libs\config\test\boost_no_unicode_literals.ipp(20): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast

[jzmaddock]

OK, I assume this is a new C++20 feature - and one that breaks existing code given that u8"xyz" was previously of type char[N]? Is there an SD6 macro for this change - I can't see anything on the "official" SD6 page yet which seems not to have caught up with C++20?

Thanks, John.

[CaseyCarter]

Hey John, Casey Carter here from MSVC.

Is there an SD6 macro for this change

My understanding is that WG21 is no longer maintaining SD-6 now that the feature-test macros are being formally standardized and have moved into the working draft for C++20. There are two feature-test macros related to char8_t: __cpp_char8_t indicates compiler support for char8_t as a type, and __cpp_lib_char8_t indicates standard library support for e.g. u8string, u8string_view, char_traits<char8_t>, etc.

And yes, u8"foo" has type const char8_t[4] in C++20 instead of const char[4] as in C++17. It's a breaking change, albeit one that WG21 thinks is for the best, but purity of motivation doesn't make it any less problematic to support in libraries that need to be portable between C++17 and C++20.

Let me know if you have any questions or if there's anything I can do to ease the fix.

[jzmaddock]

Many thanks for the clarification - the commit referenced above should hopefully fix this now.

[CaseyCarter]

Many thanks for the clarification - the commit referenced above should hopefully fix this now.

Looks right to me. Thanks for the quick response.