Support char8_t in C++17 and C++14 modes

[fsb4000]

Fixes #2106

[frederick-vs-ja]

Is there any reason to accept (or regularize) the "C++17 with char8_t" dialect, but not "C++14 with char8_t"?

[fsb4000]

Probably because <filesystem> and <string_view> are C++17.
But it seems u8string works in C++14

[fsb4000]

Maybe I should create char8_t_matrix.lst and char8_t_17_matrix.lst instead of adding the configuration to usual matrixes, shouldn't I?

[StephanTLavavej]

Yeah, changes to the usual matrices are extremely expensive because the cost of each configuration is multiplied by the large number of tests. Also, when they're changed, typically the native matrix and others need to be changed.

Since relatively little code is sensitive to this setting, I like your idea of creating a new matrix (or matrices) for a new test (or a small number of new tests). A single matrix with both C++14 and C++17 modes, with a test that has C++17-only components guarded by _HAS_CXX17, might be reasonable.

[frederick-vs-ja]

IMO we should also consider deprecation of u8path:

• if there's no char8_t, we should not deprecate it,
• otherwise, we should determine whether it is deprecated in C++17 with char8_t mode.

[StephanTLavavej]

Thanks, this looks great! I verified that all std tests mentioning char8_t, u8string, u8string_view, __cpp_char8_t, and __cpp_lib_char8_t have been updated to use the new matrices, except for tests that are inherently C++20/23. I pushed a comment change to yvals_core.h to reflect the feature-test macros, and updated the feature-test macro test's configurations to exercise the new codepath.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

Thanks for making this Future Technology available to C++14/17 users! 🚀 🛸 😸