| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: ldionne, EricWF
Subscribers: jyknight, christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 351289
|
|
|
|
|
|
| |
There were 3 tests with 'int main(void)', and 6 with the return type on a different line. I'm about to send a patch for main in tests, and this NFC change is unrelated.
llvm-svn: 350770
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
range with const-ness mismatch.
We already have a specialization that will use memcpy for construction
of trivial types from an iterator range like
std::vector<int>(int *, int *);
But if we have const-ness mismatch like
std::vector<int>(const int *, const int *);
we would use a slow path that copies each element individually. This change
enables the optimal specialization for const-ness mismatch. Fixes PR37574.
Contributions to the patch are made by Arthur O'Dwyer, Louis Dionne.
rdar://problem/40485845
Reviewers: mclow.lists, EricWF, ldionne, scanon
Reviewed By: ldionne
Subscribers: christof, ldionne, howard.hinnant, cfe-commits
Differential Revision: https://reviews.llvm.org/D48342
llvm-svn: 350583
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some tests assume that iteration through an unordered multimap elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch introduces checks verifying that any iteration will return elements
exactly from a set of valid values and without repetition, but in no
particular order.
Reviewed as https://reviews.llvm.org/D54838.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 349780
|
|
|
|
|
|
| |
https://reviews.llvm.org/D55777. Thanks to Andrey Maksimov for the patch.
llvm-svn: 349566
|
|
|
|
| |
llvm-svn: 349252
|
|
|
|
| |
llvm-svn: 349189
|
|
|
|
|
|
| |
Fundamentals 2 for C++20. Reviewed as https://reviews.llvm.org/D55532
llvm-svn: 349178
|
|
|
|
|
|
| |
bahavior. Thanks to Andrey Maksimov for the catch.
llvm-svn: 348660
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
0>.end()
The standard section [array.zero] requires the return value of begin()
and end() methods of a zero-sized array to be unique. Eric Fiselier
clarifies: "That unique value cannot be null, and must be properly aligned".
This patch adds checks for the first part of this clarification: unique
value returned by these methods cannot be null.
Reviewed as https://reviews.llvm.org/D55366.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 348509
|
|
|
|
|
|
|
|
|
|
|
| |
The section array.zero says: "The return value of data() is unspecified".
This patch marks all checks of the array<T, 0>.data() return value as
libc++ specific.
Reviewed as https://reviews.llvm.org/D55364.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 348485
|
|
|
|
|
|
|
|
|
|
|
| |
`_LIBCPP_ALIGNOF`. "
This reverts commit 087f065cb0c7463f521a62599884493aaee2ea12.
The tests were failing on 32 bit builds, and I don't have time
to clean them up right now. I'll recommit tomorrow with fixed tests.
llvm-svn: 347816
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: EricWF
Subscribers: christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 347787
|
|
|
|
| |
llvm-svn: 347672
|
|
|
|
|
|
|
|
|
|
|
|
| |
The iterator types for different specializations of containers with the
same element type but different allocators are not required to be
convertible. This patch makes the test to take the iterator type from
the same container specialization as the created container.
Reviewed as https://reviews.llvm.org/D54806.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 347423
|
|
|
|
|
|
|
| |
Reviewed as https://reviews.llvm.org/D54705.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 347233
|
|
|
|
|
|
|
|
|
|
|
| |
Some tests use type std::max_align_t, but don't include <cstddef> header
directly. As a result, these tests won't compile against some conformant
libraries.
Reviewed as https://reviews.llvm.org/D54645.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 347232
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A bunch of unordered containers tests call library functions but don't directly
include the corresponding header files:
- fabs() (defined in <cmath> which is not included);
- is_permutation() (defined in <algorithm> which is not included);
- next() (defined in <iterator> which is not included).
- As a result, these tests won't compile against some conformant libraries.
Reviewed as https://reviews.llvm.org/D54643.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 347085
|
|
|
|
| |
llvm-svn: 346914
|
|
|
|
|
|
| |
C++11's [hash.requirements] never required these typedefs from users.
llvm-svn: 346912
|
|
|
|
|
|
| |
This fixes compiler errors with MSVC's STL.
llvm-svn: 346911
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was implicitly converting [1, 3] to bool, which triggers
an MSVC warning. The test should just pass `true`, which is
simpler, has the same behavior, and avoids the warning. (This
is a library test, not a compiler test, and the conversion happens
before calling `push_back`, so passing [1, 3] isn't interesting
in any way. This resembles a previous change to stop passing
`1 == 1` in the `vector<bool>` tests.)
llvm-svn: 346910
|
|
|
|
| |
llvm-svn: 346826
|
|
|
|
|
|
|
|
| |
This patch adds tests to ensure that multiset/unordered_multiset's emplace
method correctly constructs the elements without any intervening
constructions.
llvm-svn: 346743
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a merge member function to all the map and set containers,
which splices nodes from the source container. This completes support for
P0083r3.
Differential revision: https://reviews.llvm.org/D48896
llvm-svn: 345744
|
|
|
|
|
|
| |
Reviewed as https://reviews.llvm.org/D50551
llvm-svn: 344821
|
|
|
|
| |
llvm-svn: 344417
|
|
|
|
|
|
| |
warnings. NFC
llvm-svn: 344416
|
|
|
|
| |
llvm-svn: 342524
|
|
|
|
| |
llvm-svn: 342103
|
|
|
|
|
|
| |
extra tests.
llvm-svn: 342070
|
|
|
|
| |
llvm-svn: 342057
|
|
|
|
|
|
| |
tests for all the containers that have clear().
llvm-svn: 340385
|
|
|
|
| |
llvm-svn: 339218
|
|
|
|
|
|
| |
the test_comparison routines that I committed last week. NFC.
llvm-svn: 338797
|
|
|
|
| |
llvm-svn: 338668
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a node handle type, (located in __node_handle), and adds
extract() and insert() members to all map and set types, as well as their
implementations in __tree and __hash_table.
The second half of this feature is adding merge() members, which splice nodes
in bulk from one container into another. This will be committed in a follow-up.
Differential revision: https://reviews.llvm.org/D46845
llvm-svn: 338472
|
|
|
|
| |
llvm-svn: 337808
|
|
|
|
| |
llvm-svn: 337804
|
|
|
|
| |
llvm-svn: 337016
|
|
|
|
| |
llvm-svn: 334676
|
|
|
|
| |
llvm-svn: 334056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++2a[container.requirements.general]p8 states that when move constructing
a container, the allocator is move constructed. Vector previously copy
constructed these allocators. This patch fixes that bug.
Additionally it cleans up some unnecessary allocator conversions
when copy constructing containers. Libc++ uses
__internal_allocator_traits::select_on_copy_construction to select
the correct allocator during copy construction, but it unnecessarily
converted the resulting allocator to the user specified allocator
type and back. After this patch list and forward_list no longer
do that.
Technically we're supposed to be using allocator_traits<allocator_type>::select_on_copy_construction,
but that should seemingly be addressed as a separate patch, if at all.
llvm-svn: 334053
|
|
|
|
|
|
|
| |
As discussed here: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058116.html
The tests fail on clang-5, as well as apple-clang-9. Mark them as such.
llvm-svn: 333479
|
|
|
|
|
|
| |
template deduction guides - specifically for copy-ctors
llvm-svn: 333381
|
|
|
|
|
|
| |
deduces the wrong type.
llvm-svn: 333376
|
|
|
|
|
|
| |
No matching constructor
llvm-svn: 333315
|
|
|
|
| |
llvm-svn: 332931
|
|
|
|
| |
llvm-svn: 332927
|
|
|
|
| |
llvm-svn: 332901
|