| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 300626
|
|
|
|
| |
llvm-svn: 300625
|
|
|
|
| |
llvm-svn: 300623
|
|
|
|
| |
llvm-svn: 300622
|
|
|
|
|
|
|
|
| |
std::unordered_multimap
This completes the cleanup of the containers, at least within the tests.
llvm-svn: 300620
|
|
|
|
|
|
| |
std::unordered_multiset
llvm-svn: 300619
|
|
|
|
| |
llvm-svn: 300604
|
|
|
|
| |
llvm-svn: 300602
|
|
|
|
| |
llvm-svn: 300600
|
|
|
|
| |
llvm-svn: 300595
|
|
|
|
| |
llvm-svn: 300581
|
|
|
|
| |
llvm-svn: 300575
|
|
|
|
| |
llvm-svn: 300568
|
|
|
|
| |
llvm-svn: 300533
|
|
|
|
| |
llvm-svn: 300530
|
|
|
|
|
|
|
|
|
|
| |
unique_ptr hash functions.
These tests were unconditionally asserting that optional and unique_ptr declare throwing hashes, but MSVC++ implements conditional noexcept forwarding that of the underlying hash function. As a result we were failing these tests but there's nothing forbidding strengthening noexcept in that way.
Changed the ASSERT_NOT_NOEXCEPT asserts to use types which themselves have non-noexcept hash functions.
llvm-svn: 300516
|
|
|
|
| |
llvm-svn: 300510
|
|
|
|
| |
llvm-svn: 300489
|
|
|
|
|
|
| |
(comment-only change)
llvm-svn: 300488
|
|
|
|
| |
llvm-svn: 300451
|
|
|
|
|
|
| |
extra tests
llvm-svn: 300449
|
|
|
|
| |
llvm-svn: 300417
|
|
|
|
| |
llvm-svn: 300415
|
|
|
|
| |
llvm-svn: 300414
|
|
|
|
| |
llvm-svn: 300413
|
|
|
|
| |
llvm-svn: 300412
|
|
|
|
| |
llvm-svn: 300411
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch cleans up all usages of the following feature test macros inside
<vector> and its tests:
* _LIBCPP_HAS_NO_RVALUE_REFERENCES
* _LIBCPP_HAS_NO_VARIADICS
* _LIBCPP_HAS_NO_GENERALIZED_INITIALIZERS
Where needed the above guards were replaced with _LIBCPP_CXX03_LANG.
llvm-svn: 300410
|
|
|
|
|
|
|
|
|
|
|
| |
CMake has the problem with the single dash variant because of the
space, so use the double dash with equal sign version. We also
don't have to pass the target triple when checking for compiler-rt
since that flag is already included in compile flags now.
Differential Revision: https://reviews.llvm.org/D32068
llvm-svn: 300409
|
|
|
|
| |
llvm-svn: 300408
|
|
|
|
| |
llvm-svn: 300407
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch overhauls both specializations of unique_ptr while implementing
the following LWG issues:
* LWG 2801 - This issue constrains unique_ptr's constructors when the deleter type
is not default constructible. Additionally it adds SFINAE conditions
to unique_ptr<T[]>::unique_ptr(Up).
* LWG 2905 - This issue reworks the unique_ptr(pointer, /* see below */ deleter)
constructors so that they correctly SFINAE when the deleter argument cannot
be used to construct the stored deleter.
* LWG 2520 - This issue fixes initializing unique_ptr<T[]> from nullptr.
Libc++ had previously implemented this issue, but the suggested resolution
still broke initialization from NULL. This patch re-works the
unique_ptr<T[]>(Up, deleter) overloads so that they accept NULL as well
as nullptr.
llvm-svn: 300406
|
|
|
|
|
|
|
| |
Also mark LWG 2857 as complete, since the changes to optional and
any were completed by Marshall earlier.
llvm-svn: 300403
|
|
|
|
| |
llvm-svn: 300399
|
|
|
|
| |
llvm-svn: 300397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Recent commits broke the check-cxx-abilist by changing the default OS X to use `-rexport_library` instead of `-reexport_symbol_list`. Apparently `-reexport_library` doesn't export the symbols into `libc++.dylib`s symbol table, whereas `-reexport_symbol_list` does.
This means the change removed ~500 symbols from the symbol table. I've been told this change is non ABI breaking, but it does make it harder to maintain the ABI lists, and hence the ABI.
This patch fixes the issue by switching back to `-reexport_symbol_list`. It still avoid the issues fixed in r299052 by putting the new/delete symbols in a different symbol list file, which is only exported when LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS in OFF.
Reviewers: mehdi_amini, smeenai, dexonsmith
Reviewed By: smeenai
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D31644
llvm-svn: 300390
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch almost entirely rewrites the unique_ptr tests. There are a couple
of reasons for this:
A) Most of the *.fail.cpp tests were either incorrect or could be better written
as a *.pass.cpp test that uses <type_traits> to check if certain operations
are valid (Ex. Using static_assert(!std::is_copy_constructible_v<T>) instead
of writing a failure test).
B) [unique.ptr.runtime] has very poor test coverage. Many of the constructors
and assignment operators have to tests at all. The special members that have
tests have very few test cases and are typically way out of date.
C) The tests for [unique.ptr.single] and [unique.ptr.runtime] are largely
duplicates of each other. This means common requirements have two different
sets of tests in two different test files. This makes the tests harder to
maintain than if there was a single copy.
To address (A) this patch changes almost all of the *.fail.cpp tests into
.pass.cpp tests using type traits; Allowing the *.fail.cpp tests to be removed.
The address (B) and (C) the tests for [unique.ptr.single] and [unique.ptr.runtime]
have been combined into a single directory, allowing both specializations to share
common tests. Tests specific to the single/runtime specializations are given the
suffix "*.single.pass.cpp" or "*.runtime.pass.cpp".
Finally the unique.ptr test have been moved into the correct directory according
to the standard. Specifically they have been removed from "utilities/memory" into
"utilities/smartptr".
PS. This patch also adds newly written tests for upcoming unique_ptr changes/fixes.
However since these tests don't currently pass they are guarded by the macro
TEST_WORKAROUND_UPCOMING_UNIQUE_PTR_CHANGES. This allows other STL's to validate
the tests before libc++ implements the changes. The relevant libc++ changes should
land in the next week.
llvm-svn: 300388
|
|
|
|
| |
llvm-svn: 300387
|
|
|
|
|
|
|
|
|
|
|
| |
Fuchsia's libc was forked from musl, but has evolved sufficiently
since then so it no longer makes sense to pretend it's musl. This
change implements direct support for Fuchsia rather than
piggybacking on musl support.
Differential Revision: https://reviews.llvm.org/D31970
llvm-svn: 300261
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the libc++ extern template macros were added, the intent was for it
to be possible for consumers of the headers to disable extern templates
(via `-D_LIBCPP_EXTERN_TEMPLATE(...)=`). Unfortunately, support for
specifying function-like macros varies on the command line varies across
compilers (e.g. MSVC doesn't support it at all), and cmake doesn't allow
it for the same reason. Add a non-function macro for this purpose.
The intended use is for libraries which want to use the libc++ headers
without taking a dependency on the libc++ library itself. I can name the
macro something which reflects its intent rather than its behavior (e.g.
`_LIBCPP_HEADER_ONLY`) if desired.
Differential Revision: https://reviews.llvm.org/D31725
llvm-svn: 300246
|
|
|
|
| |
llvm-svn: 300232
|
|
|
|
| |
llvm-svn: 300218
|
|
|
|
|
|
|
| |
DLLs on Windows are treated as runtime targets. Explicitly set the
output directory for them, to be consistent with other platforms.
llvm-svn: 300206
|
|
|
|
| |
llvm-svn: 300197
|
|
|
|
| |
llvm-svn: 300191
|
|
|
|
| |
llvm-svn: 300175
|
|
|
|
| |
llvm-svn: 300165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
path::iterator isn't a strictly conforming iterator. Specifically
it stashes the current element inside the iterator. This leads to
UB when used with reverse_iterator since it requires the element
to outlive the lifetime of the iterator.
This patch adds a static_assert inside reverse_iterator to disallow
"stashing iterator types", and it tags path::iterator as such a type.
Additionally this patch removes all uses of reverse_iterator<path::iterator>
within the tests.
llvm-svn: 300164
|
|
|
|
| |
llvm-svn: 300159
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::unique_ptr's default constructor must be constexpr in order
to allow constant initialization to take place for static objects;
Even though we can never have a constexpr unique_ptr variable since
it's not a literal type.
This patch adds tests that constant initialization takes place by
using the __attribute__((require_constant_initialization)) macro.
llvm-svn: 300158
|