| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
K-Ballo.
Review: http://reviews.llvm.org/D14839
llvm-svn: 255941
|
|
|
|
|
|
| |
change. Thannks to K-ballo for the patch
llvm-svn: 253593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 239664
|
|
|
|
| |
llvm-svn: 232887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch by Matthew Dempsky!
llvm-svn: 226641
|
|
|
|
| |
llvm-svn: 222794
|
|
|
|
|
|
| |
to Louis Dionne for the bug report and the patch.
llvm-svn: 219785
|
|
|
|
|
|
| |
and suggesting a more correct way to write the first
llvm-svn: 217884
|
|
|
|
| |
llvm-svn: 217878
|
|
|
|
| |
llvm-svn: 213888
|
|
|
|
|
|
| |
bug #20092. Thanks to Agustín Bergé for the bug report and the fix.
llvm-svn: 211563
|
|
|
|
|
|
| |
18853 and 19118. Add a test case for that.
llvm-svn: 206829
|
|
|
|
|
|
| |
std::tuple_element_t<> as an alias for tuple_element<>::type. Clean up the synopsis for tuple_element in <utility> as well.
llvm-svn: 202673
|
|
|
|
| |
llvm-svn: 202158
|
|
|
|
|
|
| |
to __make_tuple_return_impl; and ____iterator_traits to __iterator_traits_impl. Part of a campaign to remove > 2 underscores from libc++. No functionality change.
llvm-svn: 198457
|
|
|
|
|
|
| |
1402. This fixes http://llvm.org/bugs/show_bug.cgi?id=17798.
llvm-svn: 194154
|
|
|
|
| |
llvm-svn: 192038
|
|
|
|
|
|
| |
for the catch
llvm-svn: 191756
|
|
|
|
| |
llvm-svn: 190571
|
|
|
|
|
|
| |
explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>.
llvm-svn: 188192
|
|
|
|
|
|
| |
fixing bug #16599. Thanks to Howard for the review and updates.
llvm-svn: 186834
|
|
|
|
| |
llvm-svn: 186525
|
|
|
|
| |
llvm-svn: 186344
|
|
|
|
| |
llvm-svn: 186237
|
|
|
|
|
|
| |
tuple can be explicitly converted.
llvm-svn: 179467
|
|
|
|
|
|
| |
two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS. This is in preparation for taking advantage of clang's new __type_visibility__ attribute.
llvm-svn: 176593
|
|
|
|
|
|
| |
other system code.
llvm-svn: 167038
|
|
|
|
|
|
| |
send me a patch to CREDITS.TXT?
llvm-svn: 163862
|
|
|
|
| |
llvm-svn: 159902
|
|
|
|
| |
llvm-svn: 159865
|
|
|
|
|
|
| |
conditionalized on its held types.
llvm-svn: 159858
|
|
|
|
| |
llvm-svn: 159857
|
|
|
|
|
|
| |
is/will be making convincing arguments that a modified form of LWG 2051 (currently NAD Future) is easily acheivable and desirable. He has demonstrated that a tuple<T...> where all of the T are implicitly convertible from U... should have a tuple constructor that is also implicit, instead of explicit. This would support the use cases in LWG 2051 while not undermining T... with explicit conversions from U.... This check-in is an experimental implementation of Daniel's work. I believe this work to be mature enough to warrant inclusion into libc++. If anyone sees real-world problems that this check in causes, please let me know and I will revert it, and provide the feedback to the LWG.
llvm-svn: 153855
|
|
|
|
|
|
| |
undetected because I had failed to test assigning from a const lvalue. This fixes http://llvm.org/bugs/show_bug.cgi?id=11921
llvm-svn: 150613
|
|
|
|
| |
llvm-svn: 146881
|
|
|
|
| |
llvm-svn: 146345
|
|
|
|
| |
llvm-svn: 145624
|
|
|
|
| |
llvm-svn: 145410
|
|
|
|
| |
llvm-svn: 142235
|
|
|
|
| |
llvm-svn: 141054
|
|
|
|
| |
llvm-svn: 134190
|
|
|
|
|
|
| |
not appear to be strictly needed for correct functioning of the library. If it causes any problems, I'd rather pull it sooner rather than later.
llvm-svn: 132421
|
|
|
|
|
|
| |
for pair's swap. I needed to create an __is_nothrow_swappable<T>::value trait that was smart enought to answer false when __is_swappable<T>::value is false. Otherwise one gets compile-time errors when using pair or tuple of non-swappable types, even if you never try to swap the pair or tuple.
llvm-svn: 132204
|
|
|
|
| |
llvm-svn: 124192
|
|
|
|
|
|
|
| |
result of the __tuple_leaf::get() call to an rvalue reference when
returning from tuple's get().
llvm-svn: 124190
|