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

[Steven Cooreman via libcxx-commits]

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

`mbstate_t` needs to be visible to libc++, even when it is not relying on wide character functionality in the C library. C90 amendment 1 says that this type is to be visible through `wchar.h`. That header file should be provided by the C standard library even when that library is not implementing wchar functions (such as newlib with `--nano-formatted-io`).

The reason this guard was in place is purely historical, I believe. Tracing the modification history, I can't find any reason other than maybe `has_include_next` not having been in place at the time of creation of this file. Looking at the other include chains, libc++'s `<wchar.h>` [already unconditionally includes the underlying C lib's `wchar.h`](https://github.com/llvm/llvm-project/blob/257754011c741d96a9adbcd4858706a59bdca085/libcxx/include/wchar.h#L112C1-L117C9), so I don't really see why this guard needs to still be in place. If the C lib is providing `wchar.h`, it can be used to get hold of `mbstate_t` regardless of whether or not libc++ is allowed to call the wide char functions or not.

Tagging @ldionne for review according to the maintainer file.

>From 2689a9915b32e44a4fa6478fe3eba4c0559c6125 Mon Sep 17 00:00:00 2001
From: Steven Cooreman <steven.cooreman at silabs.com>
Date: Wed, 12 Feb 2025 15:17:23 +0100
Subject: [PATCH] [libc++] Do not guard inclusion of wchar.h with
 _LIBCPP_HAS_WIDE_CHARACTERS

mbstate_t needs to be visible to libcpp, even when it is not relying on
wide character functionality in the C library. C90 amendment 1 says that
this type is to be visible through wchar.h. That header file is provided
by the C standard library even when that library is not implementing wchar
functions (such as newlib with --nano-formatted-io).

Since we have a way to conditionally include <wchar.h> only if it exists,
we should rely on the fact that if it exists, it will provide mbstate_t.
---
 libcxx/include/__mbstate_t.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libcxx/include/__mbstate_t.h b/libcxx/include/__mbstate_t.h
index e013384454b41..e32c1dbd0c7ab 100644
--- a/libcxx/include/__mbstate_t.h
+++ b/libcxx/include/__mbstate_t.h
@@ -43,12 +43,12 @@
 #  include <bits/types/mbstate_t.h> // works on most Unixes
 #elif __has_include(<sys/_types/_mbstate_t.h>)
 #  include <sys/_types/_mbstate_t.h> // works on Darwin
-#elif _LIBCPP_HAS_WIDE_CHARACTERS && __has_include_next(<wchar.h>)
-#  include_next <wchar.h> // fall back to the C standard provider of mbstate_t
+#elif __has_include_next(<wchar.h>)
+#  include_next <wchar.h> // user the C standard provider of mbstate_t if present
 #elif __has_include_next(<uchar.h>)
-#  include_next <uchar.h> // <uchar.h> is also required to make mbstate_t visible
+#  include_next <uchar.h> // <uchar.h> can alternatively provide mbstate_t
 #else
-#  error "We don't know how to get the definition of mbstate_t without <wchar.h> on your platform."
+#  error "We don't know how to get the definition of mbstate_t on your platform."
 #endif
 
 #endif // _LIBCPP___MBSTATE_T_H