[libcxx-commits] [libcxx] [libc++] Do not guard inclusion of wchar.h with _LIBCPP_HAS_WIDE_CHARACTERS (PR #126924)

[Steven Cooreman via libcxx-commits]

stevew817 wrote:

@mordante Sure! And thanks for taking a look. The context for this is bare-metal Cortex-M class applications, where code size is of paramount concern. 99% of our applications are built with newlib-nano (aka nanolib), as shipped with ARMGCC, as the C lib. We are looking at adding support for ARM LLVM in addition to ARM GCC, while not breaking too much in existing codebases. That means providing newlib-nano/nanolib as a C library, since migrating to picolibc means having to change more than just the buildline. But since nanolib doesn't provide wchar functionality, the C++ library on top of it can't make use of wchar functions either. Which I assume is the point of even having the `_LIBCPP_HAS_WIDE_CHARACTERS` flag.

For more background on where this particular change originated from, see https://github.com/arm/arm-toolchain/pull/60

Picolibc has been hitting the same snag, by the way, but they decided to work around it by adding a mock `bits/types/mbstate_t.h`, thereby making use of the [include path for "most unixes"](https://github.com/llvm/llvm-project/blob/e167c31dc973b0b2c3af96f5e7e28d45736a6c6b/libcxx/include/__mbstate_t.h#L43) even though picolibc is absolutely not a Unix.

This change would allow picolibc to get rid of that workaround, as well as enable arm-toolchain's build of newlib-nano to not have to be patched to work around this either.

https://github.com/llvm/llvm-project/pull/126924