[libc++] Reenable codecvt in the dylib.

[mordante]

The header is used in the dylib, this is not an issue at the moment since the dylib is built using C++23.

Post release comments in #72496 seem to indicate this removal is an issue for Fuchsia, this is a test so see whether it fixes the issue for their builds.

[llvmbot]

@llvm/pr-subscribers-libcxx

Author: Mark de Wever (mordante)

Changes

The header is used in the dylib, this is not an issue at the moment since the dylib is built using C++23.

Post release comments in #72496 seem to indicate this removal is an issue for Fuchsia, this is a test so see whether it fixes the issue for their builds.

---

Full diff: https://github.com/llvm/llvm-project/pull/73679.diff

1 Files Affected:

• (modified) libcxx/include/codecvt (+2-2)

diff --git a/libcxx/include/codecvt b/libcxx/include/codecvt
index 7a363280d52127c..bdf4f7b6a201ee0 100644
--- a/libcxx/include/codecvt
+++ b/libcxx/include/codecvt
@@ -63,7 +63,7 @@ class codecvt_utf8_utf16
 #  pragma GCC system_header
 #endif
 
-#if _LIBCPP_STD_VER < 26 || defined(_LIBCPP_ENABLE_CXX26_REMOVED_CODECVT)
+#if _LIBCPP_STD_VER < 26 || defined(_LIBCPP_BUILDING_LIBRARY) || defined(_LIBCPP_ENABLE_CXX26_REMOVED_CODECVT)
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
@@ -555,7 +555,7 @@ _LIBCPP_SUPPRESS_DEPRECATED_POP
 
 _LIBCPP_END_NAMESPACE_STD
 
-#endif // _LIBCPP_STD_VER < 26 || defined(_LIBCPP_ENABLE_CXX26_REMOVED_CODECVT)
+#endif // _LIBCPP_STD_VER < 26 || defined(_LIBCPP_BUILDING_LIBRARY) || defined(_LIBCPP_ENABLE_CXX26_REMOVED_CODECVT)
 
 #if !defined(_LIBCPP_REMOVE_TRANSITIVE_INCLUDES) && _LIBCPP_STD_VER <= 20
 #  include <atomic>

[mordante]

@zeroomega @petrhosek can you test whether this fixes the issues on Fuchsia?

[ldionne]

This LGTM if this fixes Fuchsia's issues.

[zeroomega]

I can confirm this patch fixed the build failure on windows runtime with libcxx. The build step now passed without issue.
However, while our bots are down, it looks like another libcxx test failure happened:

********************
Failed Tests (4):
  llvm-libc++-static-clangcl.cfg.in :: libcxx/input.output/file.streams/fstreams/fstream.cons/wchar_pointer.pass.cpp
  llvm-libc++-static-clangcl.cfg.in :: libcxx/input.output/file.streams/fstreams/fstream.members/open_wchar_pointer.pass.cpp
  llvm-libc++-static-clangcl.cfg.in :: libcxx/input.output/file.streams/fstreams/ofstream.cons/wchar_pointer.pass.cpp
  llvm-libc++-static-clangcl.cfg.in :: libcxx/input.output/file.streams/fstreams/ofstream.members/open_wchar_pointer.pass.cpp

Failed test: https://luci-milo.appspot.com/raw/build/logs.chromium.org/fuchsia/led/haowei_google.com/7668cbff3ede0e5abbcdfe42fc7bf9d5b0e7557aa6c5fbf47d73d32db13b9676/+/build.proto

[zeroomega]

Command Output (stdout):
--
# COMPILED WITH
C:/b/s/w/ir/x/w/llvm_build/./bin/clang-cl.exe C:\b\s\w\ir\x\w\github-mordante-llvm-project\libcxx\test\libcxx\input.output\file.streams\fstreams\ofstream.members\open_wchar_pointer.pass.cpp --driver-mode=g++ --target=x86_64-pc-windows-msvc -fms-runtime-lib=static -nostdinc++ -I C:/b/s/w/ir/x/w/llvm_build/include/c++/v1 -I C:/b/s/w/ir/x/w/llvm_build/include/x86_64-pc-windows-msvc/c++/v1 -I C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_STDIO_ISO_WIDE_SPECIFIERS -DNOMINMAX -std=c++26 -Werror -Wall -Wctad-maybe-unsupported -Wextra -Wshadow -Wundef -Wunused-template -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-noexcept-type -Wno-atomic-alignment -Wno-reserved-module-identifier -Wdeprecated-copy -Wdeprecated-copy-dtor -Wno-user-defined-literals -Wno-tautological-compare -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-local-type-template-args -Wno-c++11-extensions -Wno-unknown-pragmas -Wno-pass-failed -Wno-mismatched-new-delete -Wno-redundant-move -Wno-self-move -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_ENABLE_EXPERIMENTAL -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE -Werror=thread-safety -Wuser-defined-warnings  -llibc++experimental -nostdlib -L C:/b/s/w/ir/x/w/llvm_build/./lib/x86_64-pc-windows-msvc -llibc++ -llibcpmt -o C:\b\s\w\ir\x\w\llvm_build\runtimes\runtimes-x86_64-pc-windows-msvc-bins\test\libcxx\input.output\file.streams\fstreams\ofstream.members\Output\open_wchar_pointer.pass.cpp.dir\t.tmp.exe
# executed command: C:/b/s/w/ir/x/w/llvm_build/./bin/clang-cl.exe 'C:\b\s\w\ir\x\w\github-mordante-llvm-project\libcxx\test\libcxx\input.output\file.streams\fstreams\ofstream.members\open_wchar_pointer.pass.cpp' --driver-mode=g++ --target=x86_64-pc-windows-msvc -fms-runtime-lib=static -nostdinc++ -I C:/b/s/w/ir/x/w/llvm_build/include/c++/v1 -I C:/b/s/w/ir/x/w/llvm_build/include/x86_64-pc-windows-msvc/c++/v1 -I C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_STDIO_ISO_WIDE_SPECIFIERS -DNOMINMAX -std=c++26 -Werror -Wall -Wctad-maybe-unsupported -Wextra -Wshadow -Wundef -Wunused-template -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-noexcept-type -Wno-atomic-alignment -Wno-reserved-module-identifier -Wdeprecated-copy -Wdeprecated-copy-dtor -Wno-user-defined-literals -Wno-tautological-compare -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-local-type-template-args -Wno-c++11-extensions -Wno-unknown-pragmas -Wno-pass-failed -Wno-mismatched-new-delete -Wno-redundant-move -Wno-self-move -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_ENABLE_EXPERIMENTAL -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE -Werror=thread-safety -Wuser-defined-warnings -llibc++experimental -nostdlib -L C:/b/s/w/ir/x/w/llvm_build/./lib/x86_64-pc-windows-msvc -llibc++ -llibcpmt -o 'C:\b\s\w\ir\x\w\llvm_build\runtimes\runtimes-x86_64-pc-windows-msvc-bins\test\libcxx\input.output\file.streams\fstreams\ofstream.members\Output\open_wchar_pointer.pass.cpp.dir\t.tmp.exe'
# .---command stderr------------
# | In file included from C:\b\s\w\ir\x\w\github-mordante-llvm-project\libcxx\test\libcxx\input.output\file.streams\fstreams\ofstream.members\open_wchar_pointer.pass.cpp:23:
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:38: error: no member named 'codecvt_utf8_utf16' in namespace 'std'
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |                                 ~~~~~^
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:64: error: expected '(' for function-style cast or type construction
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |                                                         ~~~~~~~^
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:66: error: expected '(' for function-style cast or type construction
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:68: error: expected expression
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |                                                                    ^
# | 4 errors generated.
# `-----------------------------
# error: command failed with exit status: 1

--

Ah, it is still related, see the test failure message.

@petrhosek and I discussed about the reason why this Fuchsia unrelated breakage wasn't caught by the upstream libcxx bots. It is likely due to the toolchain used when building libcxx and runtimes.

In our case, we always use a relatively recent clang we built to build the ToT clang. The ToT clang will then be used to build the runtime.

In upstream llvm bots, for runtime builds, it usually uses a last stable release clang to build the ToT runtime directly to reduce build time. In this case, the bug like this won't be caught until there is a new llvm stable release. I think for libcxx, at least there should be a few bots configured in a way that bots need to use ToT clang to build libcxx and corresponding runtimes for the host platform. Otherwise, breakage like this will be hide in dark.

[ldionne]

[...]

Ah, it is still related, see the test failure message.

@petrhosek and I discussed about the reason why this Fuchsia unrelated breakage wasn't caught by the upstream libcxx bots. It is likely due to the toolchain used when building libcxx and runtimes.

In our case, we always use a relatively recent clang we built to build the ToT clang. The ToT clang will then be used to build the runtime.

In upstream llvm bots, for runtime builds, it usually uses a last stable release clang to build the ToT runtime directly to reduce build time. In this case, the bug like this won't be caught until there is a new llvm stable release. I think for libcxx, at least there should be a few bots configured in a way that bots need to use ToT clang to build libcxx and corresponding runtimes for the host platform. Otherwise, breakage like this will be hide in dark.

We do have a bot that runs all of our tests against a just-built Clang using the bootstrapping build, which should catch that.

[zeroomega]

[...]

Ah, it is still related, see the test failure message.
@petrhosek and I discussed about the reason why this Fuchsia unrelated breakage wasn't caught by the upstream libcxx bots. It is likely due to the toolchain used when building libcxx and runtimes.
In our case, we always use a relatively recent clang we built to build the ToT clang. The ToT clang will then be used to build the runtime.
In upstream llvm bots, for runtime builds, it usually uses a last stable release clang to build the ToT runtime directly to reduce build time. In this case, the bug like this won't be caught until there is a new llvm stable release. I think for libcxx, at least there should be a few bots configured in a way that bots need to use ToT clang to build libcxx and corresponding runtimes for the host platform. Otherwise, breakage like this will be hide in dark.

We do have a bot that runs all of our tests against a just-built Clang using the bootstrapping build, which should catch that.

Do you have a link to that specific bots so we can take a look at the build steps and configurations?

[ldionne]

Here's a random run that succeeded with that bot: https://buildkite.com/llvm-project/libcxx-ci/builds/31767#018bfa05-2b78-4a7e-92c1-ff46e2e9fd9a. The bot has been using the same configuration for a while. We're having some infra-related issues with the bots so I didn't provide a link to the job for this specific patch, which failed spuriously.

[zeroomega]

Here's a random run that succeeded with that bot: https://buildkite.com/llvm-project/libcxx-ci/builds/31767#018bfa05-2b78-4a7e-92c1-ff46e2e9fd9a. The bot has been using the same configuration for a while. We're having some infra-related issues with the bots so I didn't provide a link to the job for this specific patch, which failed spuriously.

I just checked all 4 clang-cl bots (since this bug only happens on building windows runtime), all of them uses the clang-cl from path C:\Program Files\LLVM\bin\clang-cl.exe. They do not seem to build the ToT clang from source.

[ldionne]

Here's a random run that succeeded with that bot: https://buildkite.com/llvm-project/libcxx-ci/builds/31767#018bfa05-2b78-4a7e-92c1-ff46e2e9fd9a. The bot has been using the same configuration for a while. We're having some infra-related issues with the bots so I didn't provide a link to the job for this specific patch, which failed spuriously.

I just checked all 4 clang-cl bots (since this bug only happens on building windows runtime), all of them uses the clang-cl from path C:\Program Files\LLVM\bin\clang-cl.exe. They do not seem to build the ToT clang from source.

Ah, that's right, our bootstrapping build job runs on Linux. But regardless, I am really surprised that this type of issue would be caused by the version of Clang in use. Did you folks figure out the exact reason for the failure?

[mordante]

Command Output (stdout):
--
# COMPILED WITH
C:/b/s/w/ir/x/w/llvm_build/./bin/clang-cl.exe C:\b\s\w\ir\x\w\github-mordante-llvm-project\libcxx\test\libcxx\input.output\file.streams\fstreams\ofstream.members\open_wchar_pointer.pass.cpp --driver-mode=g++ --target=x86_64-pc-windows-msvc -fms-runtime-lib=static -nostdinc++ -I C:/b/s/w/ir/x/w/llvm_build/include/c++/v1 -I C:/b/s/w/ir/x/w/llvm_build/include/x86_64-pc-windows-msvc/c++/v1 -I C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_STDIO_ISO_WIDE_SPECIFIERS -DNOMINMAX -std=c++26 -Werror -Wall -Wctad-maybe-unsupported -Wextra -Wshadow -Wundef -Wunused-template -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-noexcept-type -Wno-atomic-alignment -Wno-reserved-module-identifier -Wdeprecated-copy -Wdeprecated-copy-dtor -Wno-user-defined-literals -Wno-tautological-compare -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-local-type-template-args -Wno-c++11-extensions -Wno-unknown-pragmas -Wno-pass-failed -Wno-mismatched-new-delete -Wno-redundant-move -Wno-self-move -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_ENABLE_EXPERIMENTAL -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE -Werror=thread-safety -Wuser-defined-warnings  -llibc++experimental -nostdlib -L C:/b/s/w/ir/x/w/llvm_build/./lib/x86_64-pc-windows-msvc -llibc++ -llibcpmt -o C:\b\s\w\ir\x\w\llvm_build\runtimes\runtimes-x86_64-pc-windows-msvc-bins\test\libcxx\input.output\file.streams\fstreams\ofstream.members\Output\open_wchar_pointer.pass.cpp.dir\t.tmp.exe
# executed command: C:/b/s/w/ir/x/w/llvm_build/./bin/clang-cl.exe 'C:\b\s\w\ir\x\w\github-mordante-llvm-project\libcxx\test\libcxx\input.output\file.streams\fstreams\ofstream.members\open_wchar_pointer.pass.cpp' --driver-mode=g++ --target=x86_64-pc-windows-msvc -fms-runtime-lib=static -nostdinc++ -I C:/b/s/w/ir/x/w/llvm_build/include/c++/v1 -I C:/b/s/w/ir/x/w/llvm_build/include/x86_64-pc-windows-msvc/c++/v1 -I C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_STDIO_ISO_WIDE_SPECIFIERS -DNOMINMAX -std=c++26 -Werror -Wall -Wctad-maybe-unsupported -Wextra -Wshadow -Wundef -Wunused-template -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-noexcept-type -Wno-atomic-alignment -Wno-reserved-module-identifier -Wdeprecated-copy -Wdeprecated-copy-dtor -Wno-user-defined-literals -Wno-tautological-compare -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-local-type-template-args -Wno-c++11-extensions -Wno-unknown-pragmas -Wno-pass-failed -Wno-mismatched-new-delete -Wno-redundant-move -Wno-self-move -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_ENABLE_EXPERIMENTAL -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE -Werror=thread-safety -Wuser-defined-warnings -llibc++experimental -nostdlib -L C:/b/s/w/ir/x/w/llvm_build/./lib/x86_64-pc-windows-msvc -llibc++ -llibcpmt -o 'C:\b\s\w\ir\x\w\llvm_build\runtimes\runtimes-x86_64-pc-windows-msvc-bins\test\libcxx\input.output\file.streams\fstreams\ofstream.members\Output\open_wchar_pointer.pass.cpp.dir\t.tmp.exe'
# .---command stderr------------
# | In file included from C:\b\s\w\ir\x\w\github-mordante-llvm-project\libcxx\test\libcxx\input.output\file.streams\fstreams\ofstream.members\open_wchar_pointer.pass.cpp:23:
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:38: error: no member named 'codecvt_utf8_utf16' in namespace 'std'
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |                                 ~~~~~^
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:64: error: expected '(' for function-style cast or type construction
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |                                                         ~~~~~~~^
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:66: error: expected '(' for function-style cast or type construction
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:68: error: expected expression
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |                                                                    ^
# | 4 errors generated.
# `-----------------------------
# error: command failed with exit status: 1

--

Ah, it is still related, see the test failure message.

I had a quick look at these failures and it seems these are Windows only tests.

@petrhosek and I discussed about the reason why this Fuchsia unrelated breakage wasn't caught by the upstream libcxx bots. It is likely due to the toolchain used when building libcxx and runtimes.

I strongly expect the libc++ toolchain on our Windows CI does not use C++26. This is something we (libc++) need to check.

In our case, we always use a relatively recent clang we built to build the ToT clang. The ToT clang will then be used to build the runtime.

Based on the failures and that this patch fixed building the dylib I have a very strong impression Fuchsia builds libc++ in C++26 mode. Can you tell what the value of the __cplusplus` macro for your compiler is. (Regardless of that value we need to fix it, but I want to understand why it fails.)

I'll look at an updated fix later today.

[petrhosek]

We're trying to reproduce the issue locally, but I see -std=c++26 in the failing test output I see the following (you need to scroll to the right to see it since the command line is so long, or just search for -std=c++26):

# COMPILED WITH
C:/b/s/w/ir/x/w/llvm_build/./bin/clang-cl.exe C:\b\s\w\ir\x\w\github-mordante-llvm-project\libcxx\test\libcxx\input.output\file.streams\fstreams\ofstream.members\open_wchar_pointer.pass.cpp --driver-mode=g++ --target=x86_64-pc-windows-msvc -fms-runtime-lib=static -nostdinc++ -I C:/b/s/w/ir/x/w/llvm_build/include/c++/v1 -I C:/b/s/w/ir/x/w/llvm_build/include/x86_64-pc-windows-msvc/c++/v1 -I C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_STDIO_ISO_WIDE_SPECIFIERS -DNOMINMAX -std=c++26 -Werror -Wall -Wctad-maybe-unsupported -Wextra -Wshadow -Wundef -Wunused-template -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-noexcept-type -Wno-atomic-alignment -Wno-reserved-module-identifier -Wdeprecated-copy -Wdeprecated-copy-dtor -Wno-user-defined-literals -Wno-tautological-compare -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-local-type-template-args -Wno-c++11-extensions -Wno-unknown-pragmas -Wno-pass-failed -Wno-mismatched-new-delete -Wno-redundant-move -Wno-self-move -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_ENABLE_EXPERIMENTAL -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE -Werror=thread-safety -Wuser-defined-warnings  -llibc++experimental -nostdlib -L C:/b/s/w/ir/x/w/llvm_build/./lib/x86_64-pc-windows-msvc -llibc++ -llibcpmt -o C:\b\s\w\ir\x\w\llvm_build\runtimes\runtimes-x86_64-pc-windows-msvc-bins\test\libcxx\input.output\file.streams\fstreams\ofstream.members\Output\open_wchar_pointer.pass.cpp.dir\t.tmp.exe
# executed command: C:/b/s/w/ir/x/w/llvm_build/./bin/clang-cl.exe 'C:\b\s\w\ir\x\w\github-mordante-llvm-project\libcxx\test\libcxx\input.output\file.streams\fstreams\ofstream.members\open_wchar_pointer.pass.cpp' --driver-mode=g++ --target=x86_64-pc-windows-msvc -fms-runtime-lib=static -nostdinc++ -I C:/b/s/w/ir/x/w/llvm_build/include/c++/v1 -I C:/b/s/w/ir/x/w/llvm_build/include/x86_64-pc-windows-msvc/c++/v1 -I C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_STDIO_ISO_WIDE_SPECIFIERS -DNOMINMAX -std=c++26 -Werror -Wall -Wctad-maybe-unsupported -Wextra -Wshadow -Wundef -Wunused-template -Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move -Wno-noexcept-type -Wno-atomic-alignment -Wno-reserved-module-identifier -Wdeprecated-copy -Wdeprecated-copy-dtor -Wno-user-defined-literals -Wno-tautological-compare -Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code -Wno-unused-local-typedef -Wno-local-type-template-args -Wno-c++11-extensions -Wno-unknown-pragmas -Wno-pass-failed -Wno-mismatched-new-delete -Wno-redundant-move -Wno-self-move -D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -D_LIBCPP_ENABLE_EXPERIMENTAL -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE -Werror=thread-safety -Wuser-defined-warnings -llibc++experimental -nostdlib -L C:/b/s/w/ir/x/w/llvm_build/./lib/x86_64-pc-windows-msvc -llibc++ -llibcpmt -o 'C:\b\s\w\ir\x\w\llvm_build\runtimes\runtimes-x86_64-pc-windows-msvc-bins\test\libcxx\input.output\file.streams\fstreams\ofstream.members\Output\open_wchar_pointer.pass.cpp.dir\t.tmp.exe'
# .---command stderr------------
# | In file included from C:\b\s\w\ir\x\w\github-mordante-llvm-project\libcxx\test\libcxx\input.output\file.streams\fstreams\ofstream.members\open_wchar_pointer.pass.cpp:23:
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:38: error: no member named 'codecvt_utf8_utf16' in namespace 'std'
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |                                 ~~~~~^
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:64: error: expected '(' for function-style cast or type construction
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |                                                         ~~~~~~~^
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:66: error: expected '(' for function-style cast or type construction
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
# | C:/b/s/w/ir/x/w/github-mordante-llvm-project/libcxx/test/support\wide_temp_file.h:23:68: error: expected expression
# |    23 |     return std::wstring_convert<std::codecvt_utf8_utf16<wchar_t> >().from_bytes(get_temp_file_name());
# |       |                                                                    ^
# | 4 errors generated.
# `-----------------------------
# error: command failed with exit status: 1

That's not something we set explicitly in our build, you can see all our CMake flags here:

llvm-project/clang/cmake/caches/Fuchsia-stage2.cmake

Lines 130 to 132 in 5e7e0d6

	set(RUNTIMES_${target}_LIBCXX_ABI_VERSION 2 CACHE STRING "")
	set(RUNTIMES_${target}_LIBCXX_ENABLE_ABI_LINKER_SCRIPT OFF CACHE BOOL "")
	set(RUNTIMES_${target}_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")

AFAICT this flag is coming from:

llvm-project/libcxx/utils/libcxx/test/params.py

Lines 107 to 120 in 5e7e0d6

	Parameter(
	name="std",
	choices=_allStandards,
	type=str,
	help="The version of the standard to compile the test suite with.",
	default=lambda cfg: next(
	s for s in reversed(_allStandards) if getStdFlag(cfg, s)
	),
	actions=lambda std: [
	AddFeature(std),
	AddSubstitution("%{cxx_std}", re.sub(r"\+", "x", std)),
	AddCompileFlag(lambda cfg: getStdFlag(cfg, std)),
	],
	),

On our builders this is going to select c++26 as the default value because with tip-of-tree Clang the following test succeeds:

$ clang++ -std=c++26 -x c++ /dev/null -fsyntax-only

However, with Clang version that's used by libc++ Buildkite builders I get:

$ clang -std=c++26 -x c++ /dev/null -fsyntax-only
error: invalid value 'c++26' in '-std=c++26'

As consequence, the logic for selecting the default version will continue through the list of C++ version and try c++23 next, that test will succeed and because of the replacement logic will pickup c++2b as the default version which is what I see in output of all libc++ Buildkite builders.

This likely explains why you haven't observed this issue but we do and it's down to our builder using the just-built Clang to compile libc++ tests.

[petrhosek]

I believe we should be able to use the following in our CMake cache file as a temporary workaround:

set(LIBCXX_TEST_PARAMS "std=c++23" CACHE STRING "")

[zeroomega]

I just fetched the toolchain from the failed task I mentioned. By default, without supplying any std flag, the __cplusplus macro value is 201402 .

I belive what @petrhosek found out about how libcxx select c++ std is the reason why we are seeing the test failures.
And that is why upstream bots is not seeing this test error.

[ldionne]

Thanks a lot for the analysis @petrhosek , this is extremely useful. So yeah the problem's on our side, basically the library fails to build in C++26 mode on Windows and we never noticed because our Windows bot is building as C++23.

[mordante]

I just fetched the toolchain from the failed task I mentioned. By default, without supplying any std flag, the __cplusplus macro value is 201402 .

I belive what @petrhosek found out about how libcxx select c++ std is the reason why we are seeing the test failures. And that is why upstream bots is not seeing this test error.

I'm quite puzzled, based on the __cplusplus you're using C++14, but when forcing C++23 things are fixed. This issue should only occur in C++26. I wonder whether this could be a side effect of f97a579?

Thanks a lot for the analysis @petrhosek , this is extremely useful. So yeah the problem's on our side, basically the library fails to build in C++26 mode on Windows and we never noticed because our Windows bot is building as C++23.

The first part of the dylib we would have found if any bot tried to build the dylib with C++26. The latest issues would require a Windows bot to test C++26.

@zeroomega @petrhosek I just pushed another commit can you test whether that completely fixes the issue for you?

[zeroomega]

@mordante I can confirm e60378bf3e56769134882356d587e7369dfac972 clears the test failure (and build failure as well) on Windows.
As @petrhosek has pointed out, the root cause of the test failure is that libcxx test configration will pass the highest c++ level supported by the clang. In this case, anyone who build libcxx with ToT clang will ran into this test failure issue. I am not sure e60378bf3e56769134882356d587e7369dfac972 is the best fix for this problem (for temporary workaround I am OK with that). If current libcxx cannot be build/test under c++26 on Windows we might want to change the way c++ level was determined by libcxx build configuration and only emit the c++ level supported. Or we should fix the libcxx and its test to perform correctly under c++26 without codecvt on Windows.

As I mentioned in #72496 (comment) , The build failure is also due to the highest C++ level was picked by the build configuration. We might want to make sure only supported C++ level was used.

[petrhosek]

@mordante @ldionne While this is being investigated and you're looking into potential solutions, would it be possible to revert #72496?

[ldionne]

@mordante CI passed. I added a comment to the effect that passing -D_LIBCPP_ENABLE_CXX26_REMOVED_CODECVT in the Windows tests is a temporary workaround, and I'm committing this now to fix the issues on Windows. We should figure out how to avoid requiring the removed codecvt in these tests in C++26, otherwise it means that users on Windows won't be able to use these constructors.

[ldionne]

@petrhosek Your issues should be fixed now, I think. Please let us know if not.

[EricWF]

What work is needed to make this not necessary?

[ldionne]

Looks like get_wide_temp_file_name() in libcxx/test/support/wide_temp_file.h is using codecvt when it shouldn't be.