[libc++] fix macro redef warning when exception is disabled

[weimingz]

Summary

when setting LIBCXX_ENABLE_EXCEPTIONS=false, _LIBCPP_NO_EXCEPTIONS wil be defined in both commandline and _config

[weimingz]

1. when setting LIBCXX_ENABLE_EXCEPTIONS=false, CMakeLists.txt passes both -fno-exception and and -D_LIBCPP_NO_EXCEPTIONS

In _config, it is defined again due to fno-exception

2. MUSL defines

typedef struct { union { int __i[6]; volatile int __vi[6]; volatile void *volatile __p[6]; } __u; } pthread_mutex_t;

and

#define PTHREAD_MUTEX_INITIALIZER {{{0}}}

The PTHREAD_MUTEX_INITIALIZER is wrong because it's partially initialized. However, even I changed it to

{{{0, 0, 0, 0, 0, 0 }}}

clang still diagnose:
"error: constexpr constructor never produces a constant expression"

If I pass -std=c++14, it is fine.

[EricWF]

include/__mutex_base

43 ↗

(On Diff #54444)

This is not OK. It's critical that mutex have a constexpr constructor that it runs during the "Constant initialization" phase of static initialization.
Heres an example of the difference this makes: https://godbolt.org/g/3cvlMJ

Also the constructor is specified as being constexpr in C++11. We can't turn that off.

If one particular pthread implementation is broken then we need a fix targeted to only that implementation. However this seems like a pthread bug and not a libc++ bug.

282 ↗

(On Diff #54444)

Same as above.

[weimingz]

include/__config

300 ↗

(On Diff #54444)

Is this change OK?

include/__mutex_base

43 ↗

(On Diff #54444)

The macro has an "#else" part. I'm not familiar with this, but it seems the constexpr an "optional feature".

[EricWF]

include/__config

300 ↗

(On Diff #54444)

Yes.

include/__mutex_base

43 ↗

(On Diff #54444)

So _LIBCPP_HAS_NO_CONSTEXPR checks for the presence of C++11 constexpr semantics. In C++14 support for constexpr was greatly increased, allowing many more expressions to be considered "constant expressions". The original macro, and _LIBCPP_HAS_NO_CXX14_CONSTXPR check if a compiler has completely implemented the C++11 or C++14 constexpr requirements respectively. In your case PTHREAD_MUTEX_INITIALIZER is defined in such a way that it requires the C++14 definition of constexpr.

[EricWF]

LGTM.

Normally system header would simply ignore this problem. However it's valuable to compile libc++ as a non-system header for both users and developers.

Than you for the patch.

[EricWF]

s/than you/thank you

libcxx/trunk/include/__config

 #define _LIBCPP_HAS_NO_TEMPLATE_ALIASES
 #endif
 
 #if __cplusplus < 201103L
 typedef __char16_t char16_t;
 typedef __char32_t char32_t;
 #endif
 
-#if !(__has_feature(cxx_exceptions))
+#if !(__has_feature(cxx_exceptions)) && !defined(_LIBCPP_NO_EXCEPTIONS)
 #define _LIBCPP_NO_EXCEPTIONS
 #endif
 
 #if !(__has_feature(cxx_rtti))
 #define _LIBCPP_NO_RTTI
 #endif
 
 #if !(__has_feature(cxx_strong_enums))