Summary: This patch adds proper guards to the is_destructible tests depending on the standard version so that they pass in c++03.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10047
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@242612 91177308-0d34-0410-b5e6-96231b3b80d8
The two main fixes this patch contains are:
- use __identity_t instead of common_type. common_type was used as an
identity metafunction but the decay resulted in incorrect results.
- Pointers to free functions were not counted as functions. Remove the pointer
before checking if a type is a function.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@239668 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Currently we only enable the use of __is_final(...) with Clang. GCC also provides __is_final(...) since 4.7 in all standard modes. This patch creates the macro _LIBCPP_HAS_IS_FINAL to note the availability of `__is_final`.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8795
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@239664 91177308-0d34-0410-b5e6-96231b3b80d8
Until GCC 5.1 the __is_trivially* intrinsics were not provided. Enable use of
the builtins for GCC 5.1.
Also enable Reference qualified member functions for GCC 4.9 and greater.
This patch also defines _GNUC_VER to 0 when __GNUC__ is not defined because
libc++ assumes _GNUC_VER is always defined.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@239653 91177308-0d34-0410-b5e6-96231b3b80d8
Replacing the dependancy on __member_function_traits with is_function allows
is_member_function_pointer to work more often. In particular it allows it to
work when we don't have variadic templates but the function has an arity > 3.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@239649 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently the conversion check does not take place in a context where access control SFINAE is applied. This patch changes the context of the test expression so that SFINAE occurs if access control does not permit the conversion.
Related bug: https://llvm.org/bugs/show_bug.cgi?id=22771
Reviewers: mclow.lists, rsmith, dim
Reviewed By: dim
Subscribers: dim, rodrigc, emaste, cfe-commits
Differential Revision: http://reviews.llvm.org/D8461
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@233552 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This patch also fixes one test case that failed in the library version of is_convertible.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8456
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@232764 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds the `<experimental/tuple>` header (almost) as specified in the latest draft of the library fundamentals TS.
The main changes in this patch are:
1. Added variable template `tuple_size_v`
2. Added function `apply(Func &&, Tuple &&)`.
3. Changed `__invoke` to be `_LIBCPP_CONSTEXPR_AFTER_CXX11`.
The `apply(...)` implementation uses `__invoke` to invoke the given function. `__invoke` already provides the required functionality. Using `__invoke` also allows `apply` to be used on pointers to member function/objects as an extension. In order to facilitate this `__invoke` has to be marked `constexpr`.
Test Plan:
Each new feature was tested.
The test cases for `tuple_size_v` are as follows:
1. tuple_size_v.pass.cpp
- Check `tuple_size_v` on cv qualified tuples, pairs and arrays.
2. tuple_size_v.fail.cpp
- Test on reference type.
3. tuple_size_v_2.fail.cpp
- Test on non-tuple
4. tuple_size_v_3.fail.cpp
- Test on pointer type.
The test cases for tuple.apply are as follows:
1. arg_type.pass.cpp
- Ensure that ref/pointer/cv qualified types are properly passed.
2. constexpr_types.pass.cpp
- Ensure constexpr evaluation of apply is possible for `tuple` and `pair`.
3. extended_types.pass.cpp
- Test apply on function types permitted by extension.
4. large_arity.pass.cpp
- Test that apply can evaluated on tuples and arrays with large sizes.
5. ref_qualifiers.pass.cpp
- Test that apply respects ref qualified functions.
6. return_type.pass.cpp
- Test that apply returns the proper type.
7. types.pass.cpp
- Test apply on function types as required by LFTS.
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4512
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@232515 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently parts of the SFINAE on tuples default constructor always gets evaluated even when the default constructor is never called or instantiated. This can cause a hard compile error when a tuple is created with types that do not have a default constructor. Below is a self contained example using a pair like class. This code will not compile but probably should.
```
#include <type_traits>
template <class T>
struct IllFormedDefaultImp {
IllFormedDefaultImp(T x) : value(x) {}
constexpr IllFormedDefaultImp() {}
T value;
};
typedef IllFormedDefaultImp<int &> IllFormedDefault;
template <class T, class U>
struct pair
{
template <bool Dummy = true,
class = typename std::enable_if<
std::is_default_constructible<T>::value
&& std::is_default_constructible<U>::value
&& Dummy>::type
>
constexpr pair() : first(), second() {}
pair(T const & t, U const & u) : first(t), second(u) {}
T first;
U second;
};
int main()
{
int x = 1;
IllFormedDefault v(x);
pair<IllFormedDefault, IllFormedDefault> p(v, v);
}
```
One way to fix this is to use `Dummy` in a more involved way in the constructor SFINAE. The following patch fixes these sorts of hard compile errors for tuple.
Reviewers: mclow.lists, rsmith, K-ballo, EricWF
Reviewed By: EricWF
Subscribers: ldionne, cfe-commits
Differential Revision: http://reviews.llvm.org/D7569
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@230120 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch introduces some black magic to detect const and volatile qualified function types such as `void () const`.
The patch works in the following way:
We first rule out any type that satisfies on of the following. These restrictions are important so that the test below works properly.
* `is_class<_Tp>::value`
* `is_union<_Tp>::value`
* `is_void<_Tp>::value`
* `is_reference<_Tp>::value`
* `__is_nullptr_t<_Tp>::value`
If none of the above is true we perform overload resolution on `__source<_Tp>(0)` to determine the return type.
* If `_Tp&` is well-formed we select `_Tp& __source(int)`. `_Tp&` is only ill formed for cv void types and cv/ref qualified function types.
* Otherwise we select `__dummy_type __source(...)`. Since we know `_Tp` cannot be void then it must be a function type.
let `R` be the returned from `__source<_Tp>(0)`.
We perform overload resolution on `__test<_Tp>(R)`.
* If `R` is `__dummy_type` we call `true_type __test(__dummy_type)`.
* if `R` is `_Tp&` and `_Tp&` decays to `_Tp*` we call `true_type __test(_Tp*)`. Only references to function types decay to a pointer of the same type.
* In all other cases we call `false_type __test(...)`.
`__source<_Tp>(0)` will try and form `_Tp&` in the return type. if `_Tp&` is not well formed the return type of `__source<_Tp>(0)` will be dummy type. `_Tp&` is only ill-formed for cv/ref qualified function types (and void which is dealt with elsewhere).
This fixes PR20084 - http://llvm.org/bugs/show_bug.cgi?id=20084
Reviewers: rsmith, K-ballo, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7573
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@229696 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The requirement on the `Size` type passed to *_n algorithms is that it is convertible to an integral type. This means we can't use a variable of type `Size` directly. Instead we need to convert it to an integral type first. The problem is finding out what integral type to convert it to. `__convert_to_integral` figures out what integral type to convert it to and performs the conversion, It also promotes the resulting integral type so that it is at least as big as an integer. `__convert_to_integral` also has a special case for converting enums. This should only work on non-scoped enumerations because it does not apply an explicit conversion from the enum to its underlying type.
Reviewers: chandlerc, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7449
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@228704 91177308-0d34-0410-b5e6-96231b3b80d8
Delay instantiation of `__numeric_type` within <cmath>,
don't instantiate it when the `is_arithmetic` conditions do not hold as it causes
errors with user-defined types with ambiguous conversions. Fixes PR21083.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@219998 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This patch moves the SFINAE for __is_destructor_welformed out of the function template parameters. type_traits must compile in c++03 mode since it is included in c++03 headers.
Test Plan: No tests have been added.
Reviewers: danalbert, mclow.lists
Reviewed By: danalbert
Subscribers: K-ballo, cfe-commits
Differential Revision: http://reviews.llvm.org/D4735
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@214422 91177308-0d34-0410-b5e6-96231b3b80d8
Error 1 error C2681: 'add_rvalue_reference<_Tp*>::type' : invalid expression
type for dynamic_cast c:\libcxx\include\type_traits
This is one more step getting libcxx compile under Visual C++. The patch is
#if defined(_LIBCPP_MSVC) so will affect only this build.
When libcxx can be compiled, it will probably require the current version or
maybe even the next Update of Visual C++ 2013.
Patch by G M!
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@201844 91177308-0d34-0410-b5e6-96231b3b80d8
pair, and a couple of pair-like implementation detail types. The
C++98/03 and 11 standards all specify that the copy constructor of
pair<int, int> is trivial. However as libc++ tracked the draft C++11
standard over the years, this copy constructor became non-trivial, and
then just recently was corrected back to trivial for C++11.
Unfortunately (for libc++1) the Itanium ABI specifies different calling
conventions for trivial and non-trivial copy constructors. Therefore
currently the C++03 libc++ copy constructor for pair<int, int> is ABI
incompatible with the C++11 libc++ copy constructor for pair<int, int>.
This is Bad(tm). This patch corrects the situation by making this copy
constructor trivial in C++03 mode as well.
Just in case it is needed for an incomplete C++11 compiler, libc++
retains the ability to support pair with rvalue references, but without
defaulted special members. However the pair needs non-trivial special
members to implement this special case, (as it did when clang was in
this place a couple of years ago).
During this work a bug was also found and fixed in
is_trivially_constructible.
And there is a minor drive-by fix in <__config> regarding
__type_visibility__.
A test is updated to ensure that the copy constructor of pair<int, int>
is trivial in both C++03 and C++11. This test will necessarily fail for
a compiler that implements rvalue references but not defaulted special
members.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@194536 91177308-0d34-0410-b5e6-96231b3b80d8
