| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 224658
|
|
|
|
|
|
| |
test/utilities because optional was going to be part of C++14, and then was pulled and put into the Library Fundamentals TS instead. No funcitonality change here; just moving files around.
llvm-svn: 223778
|
|
|
|
|
|
| |
bad_optional_access to match the Library Fundamentals draft standard. This is not all of the upcoming changes to optional, though.
llvm-svn: 223775
|
|
|
|
| |
llvm-svn: 222278
|
|
|
|
|
|
| |
test as well.
llvm-svn: 222242
|
|
|
|
|
|
| |
add tests. Mark LWG2400 and LWG2404 as complete
llvm-svn: 222161
|
|
|
|
| |
llvm-svn: 222143
|
|
|
|
|
|
| |
before C++1z. Update the 1z status page, marking a bunch of issues that don't require library changes as complete (2129, 2212, 2230, 2233, 2325, 2365, 2376)
llvm-svn: 222138
|
|
|
|
|
|
| |
was added to C++1z with the adoption of N4277, but libc++ already implemented it as a conforming extension. No code changes were needed, just more tests.
llvm-svn: 222132
|
|
|
|
| |
llvm-svn: 221398
|
|
|
|
| |
llvm-svn: 221395
|
|
|
|
| |
llvm-svn: 221240
|
|
|
|
|
|
|
| |
tests that replace operator new/delete won't link when using ASAN and MSAN
because these sanitizers also replace new/delete.
llvm-svn: 221236
|
|
|
|
| |
llvm-svn: 221224
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch add support for "fancy pointers/allocators" as well as fixing support for shared_pointer and "minimal" allocators.
Fancy pointers are class types that meet the NullablePointer requirements. In our case they are created by fancy allocators. `support/min_allocator.h` is an archetype for these types.
There are three types of changes made in this patch:
1. `_Alloc::template rebind<T>::other` -> `__allocator_traits_rebind<_Alloc, T>::type`. This change was made because allocators don't need a rebind template. `__allocator_traits_rebind` is used instead of `allocator_traits::rebind` because use of `allocator_traits::rebind` requires a workaround for when template aliases are unavailable.
2. `a.deallocate(this, 1)` -> `a.deallocate(pointer_traits<self>::pointer_to(*this), 1)`. This change change is made because fancy pointers aren't always constructible from raw pointers.
3. `p.get()` -> `addressof(*p.get())`. Fancy pointers aren't actually a pointer. When we need a "real" pointer we take the address of dereferencing the fancy pointer. This should give us the actual raw pointer.
Test Plan: Tests were added using `support/min_allocator.h` to each affected shared_ptr overload and creation function. These tests can only be executed in C++11 or greater since min_allocator is only available then. A extra test was added for the non-variadic versions of allocate_shared.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4859
llvm-svn: 220469
|
|
|
|
|
|
| |
support first.
llvm-svn: 220465
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
functionality change
llvm-svn: 220142
|
|
|
|
|
|
| |
to Louis Dionne for the bug report and the patch.
llvm-svn: 219785
|
|
|
|
|
|
| |
specification'. Thanks to Louis Dionne for the fix.
llvm-svn: 219243
|
|
|
|
|
|
| |
non-const references as 'right hand side'. Add tests. Fixes PR# 20836
llvm-svn: 218286
|
|
|
|
|
|
|
|
|
|
| |
If you're crazy enough to want this sort of thing, then add
-D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and
--param=additiona_features=libcpp-has-no-threads to your lit commnad line.
http://reviews.llvm.org/D3969
llvm-svn: 217271
|
|
|
|
|
|
|
|
| |
available_features
http://reviews.llvm.org/D5214
llvm-svn: 217261
|
|
|
|
|
|
|
|
|
|
|
| |
This modifies the use_clang_verify parameter I added in r217009 to
only apply to tests that specifically ask for it via // USE_VERIFY.
This allows us to incrementally convert tests, but start enjoying the
benefits right away.
Suggested by Eric Fiselier in code review.
llvm-svn: 217017
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, failure tests work by checking that compilation exits 1.
This can lead to tests that fail for the wrong reason, so it'd be
preferable to convert them to check for specific errors.
This adds use_clang_verify parameter that runs failure tests using
clang's -verify flag. I'll convert some tests in subsequent commits,
and once all of the tests are converted we should key this on whether
cxx_under_test is clang.
I've also converted one of the unique.ptr tests, since it's the one
that motivated the idea of using clang -verify when possible in the
review of r216317.
llvm-svn: 217009
|
|
|
|
|
|
| |
http://reviews.llvm.org/D4045
llvm-svn: 216949
|
|
|
|
|
|
| |
unknown bound' Thanks to K-ballo for the bug report. Update a few of the other tests while we're here, and fix a typo in a test name.
llvm-svn: 216909
|
|
|
|
| |
llvm-svn: 216318
|
|
|
|
|
|
| |
Coverity Scan.
llvm-svn: 216317
|
|
|
|
| |
llvm-svn: 215985
|
|
|
|
|
|
|
|
| |
from Agustin Berge.
I reviewed the patch and added the test cases.
llvm-svn: 215984
|
|
|
|
| |
llvm-svn: 215769
|
|
|
|
|
|
| |
predicates to fail. Add a test to make sure it works. However, most of the reference_wrapper tests still fail in C++03 mode, due to a lack of decltype. No change there.
llvm-svn: 214760
|
|
|
|
| |
llvm-svn: 213888
|
|
|
|
| |
llvm-svn: 213163
|
|
|
|
|
|
| |
std::function results in half-empty state' Thanks to Agustin Berge for the report, and for his and Eric Fiselier's work on a fix.
llvm-svn: 212070
|
|
|
|
|
|
|
| |
The maximum alignment on arm is 8, not 16 like on x86. Use alignof(max_align_t)
to make the test work in both cases.
llvm-svn: 210195
|
|
|
|
|
|
| |
libc++) to stop working. And tests
llvm-svn: 209785
|
|
|
|
| |
llvm-svn: 207307
|
|
|
|
|
|
| |
18853 and 19118. Add a test case for that.
llvm-svn: 206829
|
|
|
|
|
|
| |
allocator, not construct one from scratch. Add a test to make sure
llvm-svn: 206623
|
|
|
|
|
|
| |
see if they were supported in the language. This resulted in a warning when testing using C++03.
llvm-svn: 206482
|
|
|
|
|
|
|
|
|
|
| |
__[u]int128_t
This commit also adds tests for std::numeric_limits<__[u]int128_t>.
Reviewed in http://llvm-reviews.chandlerc.com/D2917
llvm-svn: 204849
|
|
|
|
|
|
| |
libc++ already does the right thing here; I've just added tests to ensure that it stays this way.
llvm-svn: 203539
|
|
|
|
| |
llvm-svn: 202991
|
|
|
|
|
|
| |
modern versions of clang provide. Also mark LWG #2230 as complete - no code changes needed.
llvm-svn: 202934
|
|
|
|
|
|
| |
for already existing move semantics. Mark LWG issues #2315 (no changes needed), 2316 (move semantics for weak_ptr), 2252 (previous commit) and 2271 (previous commit) as complete.
llvm-svn: 202931
|
|
|
|
|
|
| |
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
|