[libc++] Include "bits/alltypes.h" to provide mbstate_t when using musl libc

[pzheng]

Summary

With D148542, we ran into the following libc++ build error when using musl libc.

.../musl/include/bits/alltypes.h:354:16:
error: definition of type '__mbstate_t' conflicts with typedef of the same name
typedef struct __mbstate_t { unsigned __opaque1, __opaque2; } mbstate_t;
               ^
.../sysroot/usr/include/bits/types/__mbstate_t.h:21:3: note: '__mbstate_t' declared here
} __mbstate_t;
  ^
1 error generated.

This is because the mbstate_t definition in musl libc conflicts with the one
from "bits/types/mbstate_t.h", and this patch attempts to fix this build issue
when musl libc is used.

[iana]

Thanks for doing this one!

libcxx/include/__mbstate_t.h

39

Should we undef this after including alltypes?

[pzheng]

Add undef after include

[pzheng]

libcxx/include/__mbstate_t.h

39

That's a good point! I just added undef in the latest revision.

[philnik]

Please don't land libc++ patches until the libc++ group has approved.

[pzheng]

In D151740#4384276, @philnik wrote:

Please don't land libc++ patches until the libc++ group has approved.

Oops, sorry for my ignorance, @philnik... I didn't know this rule existed for libc++ patch reviews. Thank you for educating me.

[Mordante]

In D151740#4384671, @pzheng wrote:

In D151740#4384276, @philnik wrote:

Please don't land libc++ patches until the libc++ group has approved.

Oops, sorry for my ignorance, @philnik... I didn't know this rule existed for libc++ patch reviews. Thank you for educating me.

In general in Phabricator when there are blocking reviewers you should wait on their approval.

[pzheng]

In D151740#4384719, @Mordante wrote:

In D151740#4384671, @pzheng wrote:

In D151740#4384276, @philnik wrote:

Please don't land libc++ patches until the libc++ group has approved.

Oops, sorry for my ignorance, @philnik... I didn't know this rule existed for libc++ patch reviews. Thank you for educating me.

In general in Phabricator when there are blocking reviewers you should wait on their approval.

Thanks for pointing it out, @Mordante. Again, my apologies for overlooking this.

libcxx/include/__mbstate_t.h

 // We define this here to support older versions of glibc <wchar.h> that do
 // not define this for clang. This is also set in libc++'s <wchar.h> header,
 // and we need to do so here too to avoid a different function signature given
 // a different include order.
 #ifdef __cplusplus
 #  define __CORRECT_ISO_CPP_WCHAR_H_PROTO
 #endif
 
-#if __has_include(<bits/types/mbstate_t.h>)
+#if defined(_LIBCPP_HAS_MUSL_LIBC)
+#   define __NEED_mbstate_t
+#   include <bits/alltypes.h>
+#   undef __NEED_mbstate_t
+#elif __has_include(<bits/types/mbstate_t.h>)
 #   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 !defined(_LIBCPP_HAS_NO_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(<uchar.h>)
 #   include_next <uchar.h> // <uchar.h> is also required to make mbstate_t visible
 #else
 #   error "We don't know how to get the definition of mbstate_t without <wchar.h> on your platform."
 #endif
 
 #endif // _LIBCPP___MBSTATE_T_H