| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
to Louis Dionne for the bug report and the patch.
llvm-svn: 219785
|
| |
|
|
| |
llvm-svn: 213888
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
fixing bug #16599. Thanks to Howard for the review and updates.
llvm-svn: 186834
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 119395
|
| |
|
|
| |
llvm-svn: 111767
|
| |
|
|
| |
llvm-svn: 103516
|
|
|
llvm-svn: 103490
|
