The test was previously set to XFAIL if __cpp_structured_bindings
wasn't defined. However there are Clang 4.0 versions which do not
define this macro but do provide structured bindings, which causes
the test to pass unexpectedly.
This patch changes the XFAIL to an UNSUPPORTED.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291060 91177308-0d34-0410-b5e6-96231b3b80d8
In ABI v1 libc++ implements std::pointer_safety as a class type instead
of an enumeration. However this class type does not provide
a default constructor as it should. This patch adds that default constructor.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291059 91177308-0d34-0410-b5e6-96231b3b80d8
In the C++ standard `std::pointer_safety` is defined
as a C++11 strongly typed enum. However libc++ currently defines
it as a class type which simulates a C++11 enumeration. This
can be detected in valid C++ code.
This patch introduces an the _LIBCPP_ABI_POINTER_SAFETY_ENUM_TYPE ABI option.
When defined `std::pointer_safety` is implemented as an enum type.
Unfortunatly this also means it can no longer be provided as an extension
in C++03.
Additionally this patch moves the definition for `get_pointer_safety()`
out of the dylib, and into the headers. New usages of `get_pointer_safety()`
will now use the inline version instead of the dylib version. However in
order to keep the dylib ABI compatible the old definition is explicitly
compiled into it.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291046 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch attempts to re-implement a fix for LWG 2770, but not the actual specified PR.
The PR for 2770 specifies tuple_size<T const> as only conditionally providing a `::value` member. However C++17 structured bindings require `tuple_size<T const>` to be complete only if `tuple_size<T>` is also complete. Therefore this patch implements only provides the specialization `tuple_size<T CV>` iff `tuple_size<T>` is a complete type.
This fixes http://llvm.org/PR31513.
Reviewers: mclow.lists, rsmith, mpark
Subscribers: mpark, cfe-commits
Differential Revision: https://reviews.llvm.org/D28222
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@291019 91177308-0d34-0410-b5e6-96231b3b80d8
These tests were using malloc()'s return value without checking for null,
which MSVC's /analyze rightly warns about. Asserting that the pointer is
non-null both expresses the test's intention and silences the warning.
Fixes D27785.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290921 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements the correct PR for LWG 2770. It also makes the primary
tuple_size template incomplete again which fixes part of llvm.org/PR31513.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290846 91177308-0d34-0410-b5e6-96231b3b80d8
There were two problems with the initial fix.
1. The added tests flushed out that we misconfigured _LIBCPP_EXPLICIT with GCC.
2. Because the boolean type was a member function template it caused weird link
errors. I'm assuming due to the vague linkage rules. This time the bool type
is a non-template member function pointer. That seems to have fixed the
failing tests. Plus it will end up generating less symbols overall, since
the bool type is no longer per instantiation.
original commit message below
-----------------------------
std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.
However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.
This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290754 91177308-0d34-0410-b5e6-96231b3b80d8
std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.
However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.
This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290750 91177308-0d34-0410-b5e6-96231b3b80d8
Back in r240527 I added a knob to prevent thread-unsafe functions from
being exposed. mblen(), mbtowc() and wctomb() were also added to this
list, as the latest issue of POSIX doesn't require these functions to be
thread-safe.
It turns out that the only circumstance in which these functions are not
thread-safe is in case they are used in combination with state-dependent
character sets (e.g., Shift-JIS). According to Austin Group Bug 708,
these character sets "[...] are mostly a relic of the past and which
were never supported on most POSIX systems".
Though in many cases the use of these functions can be prevented by
using the reentrant counterparts, they are the only functions that allow
you to query whether the locale's character set is state-dependent. This
means that omitting these functions removes actual functionality.
Let's be a bit less pedantic and drop the guards around these functions.
Links:
http://austingroupbugs.net/view.php?id=708http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2037.htm
Reviewed by: ericwf
Differential Revision: https://reviews.llvm.org/D21436
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290748 91177308-0d34-0410-b5e6-96231b3b80d8
This patch reverts the changes to tuple which fixed construction from
types derived from tuple. It breaks the code mentioned in llvm.org/PR31384.
I'll follow this commit up with a test case.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@289773 91177308-0d34-0410-b5e6-96231b3b80d8
