[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

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

Same as above.

[weimingz]

include/__config

300

Is this change OK?

include/__mutex_base

43

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

[EricWF]

include/__config

300

Yes.

include/__mutex_base

43

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

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))

include/__mutex_base

 #endif  // _LIBCPP_THREAD_SAFETY_ANNOTATION
 
 class _LIBCPP_TYPE_VIS _LIBCPP_THREAD_SAFETY_ANNOTATION(capability("mutex")) mutex
 {
     pthread_mutex_t __m_;
 
 public:
     _LIBCPP_INLINE_VISIBILITY
-#ifndef _LIBCPP_HAS_NO_CONSTEXPR
+#ifndef _LIBCPP_HAS_NO_CXX14_CONSTEXPR
      constexpr mutex() _NOEXCEPT : __m_(PTHREAD_MUTEX_INITIALIZER) {}
 #else
      mutex() _NOEXCEPT {__m_ = (pthread_mutex_t)PTHREAD_MUTEX_INITIALIZER;}
 #endif
      ~mutex();
 
 private:
     mutex(const mutex&);// = delete;

 };
 _LIBCPP_DECLARE_STRONG_ENUM_EPILOG(cv_status)
 
 class _LIBCPP_TYPE_VIS condition_variable
 {
     pthread_cond_t __cv_;
 public:
     _LIBCPP_INLINE_VISIBILITY
-#ifndef _LIBCPP_HAS_NO_CONSTEXPR
+#ifndef _LIBCPP_HAS_NO_CXX14_CONSTEXPR
     constexpr condition_variable() : __cv_(PTHREAD_COND_INITIALIZER) {}
 #else
     condition_variable() {__cv_ = (pthread_cond_t)PTHREAD_COND_INITIALIZER;}
 #endif
     ~condition_variable();
 
 private:
     condition_variable(const condition_variable&); // = delete;