| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 224658
|
|
|
|
| |
llvm-svn: 222278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template instantiation depth. Fixes Bug #18345
Summary:
http://llvm.org/bugs/show_bug.cgi?id=18345
Tuple's constructor and assignment operators for "tuple-like" types evaluates __make_tuple_types unnecessarily. In the case of a large array this can blow the template instantiation depth.
Ex:
```
#include <array>
#include <tuple>
#include <memory>
typedef std::array<int, 1256> array_t;
typedef std::tuple<array_t> tuple_t;
int main() {
array_t a;
tuple_t t(a); // broken
t = a; // broken
// make_shared uses tuple behind the scenes. This bug breaks this code.
std::make_shared<array_t>(a);
}
```
To prevent this from happening we delay the instantiation of `__make_tuple_types` until after we perform the length check. Currently `__make_tuple_types` is instantiated at the same time that the length check .
Test Plan: Two tests have been added. One for the "tuple-like" constructors and another for the "tuple-like" assignment operator.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: K-ballo, cfe-commits
Differential Revision: http://reviews.llvm.org/D4467
llvm-svn: 220769
|
|
|
|
|
|
| |
available if <array> or <utility> are included (not just <tuple>). We already do this. Add some tests to make sure that this remains true.
llvm-svn: 220295
|
|
|
|
|
|
| |
to Louis Dionne for the bug report and the patch.
llvm-svn: 219785
|
|
|
|
|
|
| |
specification'. Thanks to Louis Dionne for the fix.
llvm-svn: 219243
|
|
|
|
| |
llvm-svn: 213888
|
|
|
|
| |
llvm-svn: 207307
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
functionality change. Fixes 18291. Thanks to Nico for the bug report and the patch.
llvm-svn: 199400
|
|
|
|
|
|
| |
Moved one to /support, removed the other, and iupdated all the includes. No functionality change
llvm-svn: 196127
|
|
|
|
|
|
| |
Moved one to /support, removed the other, and iupdated all the includes. No functionality change
llvm-svn: 196118
|
|
|
|
| |
llvm-svn: 192038
|
|
|
|
| |
llvm-svn: 187906
|
|
|
|
|
|
| |
fixing bug #16599. Thanks to Howard for the review and updates.
llvm-svn: 186834
|
|
|
|
| |
llvm-svn: 186237
|
|
|
|
|
|
| |
tuple can be explicitly converted.
llvm-svn: 179467
|
|
|
|
| |
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
|
|
|
|
|
|
| |
(http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1385). This issue is only in Ready status, meaning it is not official, but probably will be this March in Madrid. It was tentatively accepted in Batavia with the previso that Bill and I didn't have any problems implementing it. This is my part of that agreement.
llvm-svn: 121619
|
|
|
|
| |
llvm-svn: 119545
|
|
|
|
| |
llvm-svn: 119541
|
|
|
|
| |
llvm-svn: 119395
|
|
|
|
|
|
| |
flags, and renamed _LIBCPP_MOVE to _LIBCPP_HAS_NO_RVALUE_REFERENCES to be more consistent with the rest of the libc++'s flags, and with clang's nomenclature.
llvm-svn: 113086
|
|
|
|
| |
llvm-svn: 111767
|
|
|
|
| |
llvm-svn: 111546
|
|
|
|
| |
llvm-svn: 111542
|
|
|
|
| |
llvm-svn: 105393
|
|
|
|
| |
llvm-svn: 103516
|
|
llvm-svn: 103490
|