Home
last modified time | relevance | path

Searched hist:"8551 d0e3" (Results 1 – 2 of 2) sorted by relevance

/llvm-project-15.0.7/libcxx/test/std/thread/thread.mutex/thread.mutex.requirements/thread.mutex.requirements.mutex/thread.mutex.class/
H A Ddefault.pass.cpp8551d0e3 Wed Jun 07 20:47:42 GMT 2017 Eric Fiselier <[email protected]> Fix compile error with Bionic's PTHREAD_MUTEX_INITIALIZER

On Bionic PTHREAD_MUTEX_INITIALIZER contains the expression "<enum-type> & <integer-type>",
which causes ADL to perform name lookup for operator&. During this lookup Clang decides
that it requires the default member initializer for std::mutex while defining the DMI
for std::mutex::__m_.

If I'm not mistaken this is caused by the explicit noexcept declaration on the defaulted
constructor.

This patch removes the explicit noexcept and instead allows the compiler to declare
the default constructor implicitly noexcept. It also adds a static_assert to ensure
that happens.

Unfortunatly because it's not easy to change the value of _LIBCPP_MUTEX_INITIALIZER
for a single test there is no good way to test this patch.

The Clang behavior causing the trouble here was introduced in r287713, which first
appears in the 4.0 release.

llvm-svn: 304942
/llvm-project-15.0.7/libcxx/include/
H A D__mutex_base8551d0e3 Wed Jun 07 20:47:42 GMT 2017 Eric Fiselier <[email protected]> Fix compile error with Bionic's PTHREAD_MUTEX_INITIALIZER

On Bionic PTHREAD_MUTEX_INITIALIZER contains the expression "<enum-type> & <integer-type>",
which causes ADL to perform name lookup for operator&. During this lookup Clang decides
that it requires the default member initializer for std::mutex while defining the DMI
for std::mutex::__m_.

If I'm not mistaken this is caused by the explicit noexcept declaration on the defaulted
constructor.

This patch removes the explicit noexcept and instead allows the compiler to declare
the default constructor implicitly noexcept. It also adds a static_assert to ensure
that happens.

Unfortunatly because it's not easy to change the value of _LIBCPP_MUTEX_INITIALIZER
for a single test there is no good way to test this patch.

The Clang behavior causing the trouble here was introduced in r287713, which first
appears in the 4.0 release.

llvm-svn: 304942