| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 284943
|
|
|
|
| |
llvm-svn: 283633
|
|
|
|
|
|
|
| |
I think I've solved issues with is_assignable and references to incomplete
types. The updated patch adds tests for this case.
llvm-svn: 276603
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a breaking change. The SFINAE required is instantiated the second
the class is instantiated, and this can cause hard SFINAE errors
when applied to references to incomplete types. Ex.
struct IncompleteType;
extern IncompleteType it;
std::tuple<IncompleteType&> t(it); // SFINAE will blow up.
llvm-svn: 276598
|
|
|
|
| |
llvm-svn: 276583
|
|
|
|
| |
llvm-svn: 276548
|
|
|
|
| |
llvm-svn: 275748
|
|
|
|
|
|
|
|
|
|
| |
This patch upgrades <tuple> to be C++17 compliant by implementing:
* tuple_size_v: This was forgotten when implementing the other _v traits.
* std::apply: This was added via LFTS v1 in p0220r1.
* std::make_from_tuple: This was added in p0209r2.
llvm-svn: 275745
|
|
|
|
| |
llvm-svn: 274422
|
|
|
|
| |
llvm-svn: 274418
|
|
|
|
| |
llvm-svn: 274414
|
|
|
|
| |
llvm-svn: 274413
|
|
|
|
|
|
|
|
|
|
| |
This patch attempts to improve the QoI of std::tuples tuple_element and
__make_tuple_types helpers. Previously they required O(N) instantiations,
one for every element in the tuple
The new implementations are O(1) after __tuple_indices<Id...> is created.
llvm-svn: 274330
|
|
|
|
| |
llvm-svn: 273367
|
|
|
|
| |
llvm-svn: 273357
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
some cases.
Libc++ has to deduce the 'allocator_arg_t' parameter as 'AllocArgT' for the
following constructor:
template <class Alloc> tuple(allocator_arg_t, Alloc const&)
Previously libc++ has tried to support tags derived from 'allocator_arg_t' by
using 'is_base_of<AllocArgT, allocator_arg_t>'. However this breaks whenever a
2-tuple contains a reference to an incomplete type as its first parameter.
See https://llvm.org/bugs/show_bug.cgi?id=27684
llvm-svn: 273334
|
|
|
|
|
|
| |
warnings enabled
llvm-svn: 272822
|
|
|
|
|
|
|
|
|
| |
TEST_STD_VER.
This is a huge cleanup that helps make the libc++ test suite more portable.
Patch from STL@microsoft.com. Thanks STL!
llvm-svn: 272716
|
|
|
|
| |
llvm-svn: 271435
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quite a few libcxx tests seem to follow the format:
#if _LIBCPP_STD_VER > X
// Do test.
#else
// Empty test.
#endif
We should instead use the UNSUPPORTED lit directive to exclude the test on
earlier C++ standards. This gives us a more accurate number of test passes
for those standards and avoids unnecessary conflicts with other lit
directives on the same tests.
Reviewers: bcraig, ericwf, mclow.lists
Differential revision: http://reviews.llvm.org/D20730
llvm-svn: 271108
|
|
|
|
| |
llvm-svn: 271065
|
|
|
|
| |
llvm-svn: 267852
|
|
|
|
| |
llvm-svn: 267131
|
|
|
|
| |
llvm-svn: 266703
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two main fixes in this patch.
First the constructor SFINAE was changed so that it's evaluated in two stages
where the first stage evaluates the "safe" SFINAE conditions and the second
evaluates the "dangerous" ones. The key is that the second stage is lazily
evaluated only if the first stage passes. This helps fix PR23256
(https://llvm.org/bugs/show_bug.cgi?id=23256).
The second fix is for PR22806 and LWG issue 2549. This fix applies
the suggested resolution to the LWG issue in order to prevent the construction
of dangling references. The SFINAE for this check is contained within
the _PreferTupleLikeConstructor alias template. The tuple-like constructors
are disabled whenever that trait returns false.
(https://llvm.org/bugs/show_bug.cgi?id=22806)
(http://cplusplus.github.io/LWG/lwg-active.html#2549)
llvm-svn: 266461
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uses-allocator constructors
Summary:
A default uses-allocator constructor has been added since that overload was previously provided by the extended constructor.
Since Clang does implicit conversion checking after substitution this constructor has to deduce the allocator_arg_t parameter so that it can prevent the evaluation of "is_default_constructible" if the first argument doesn't match. See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1391 for more information.
This patch fixes PR24779 (https://llvm.org/bugs/show_bug.cgi?id=24779)
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19006
llvm-svn: 266409
|
|
|
|
| |
llvm-svn: 255944
|
|
|
|
|
|
|
| |
K-Ballo.
Review: http://reviews.llvm.org/D14839
llvm-svn: 255941
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
default constructor if it is not needed.
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
llvm-svn: 230120
|
|
|
|
| |
llvm-svn: 229810
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: No declaration for the type `tuple` is given in c++03 or c++98 modes. Mark all tests that use the actual `tuple` type as UNSUPPORTED.
Reviewers: jroelofs, mclow.lists, danalbert
Reviewed By: danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5956
llvm-svn: 229808
|
|
|
|
| |
llvm-svn: 228344
|
|
|
|
|
|
| |
support/, remove the other, and update all the tests that included them. No functionality change.
llvm-svn: 227370
|
|
|
|
|
|
| |
match what was in the standard. Added these includes to the tests. No changes to the library or test results.
llvm-svn: 225541
|
|
llvm-svn: 224658
|