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
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
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
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
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
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
The __unordered_map_equal and __unordered_map_hash wrappers
attempt to swap const qualified predicates whenever the predicate
is empty, and is subject to the EBO.
Swapping const values seems blatently incorrect. This patch removes
the const qualifier so the values are swapped as non-const.
llvm-svn: 300154
r300140 introduced a bunch of failures by changing the internal
interface provided by __compressed_pair. This patch fixes all of
the failures caused by the new interface by changing the existing
code to use it.
In addition to those changes this patch also fixes two separate
issues causing test failures:
1) Fix the member swap definition for __map_value_compare. Previously
the swap was incorrectly configured to swap the comparator as const.
2) Fix an assertion failure in futures.task.members/ctor_func_alloc.pass.cpp
that incorrectly expected a move to take place when a single copy is sufficient.
There is one remaining failure regarding make_shared. I'll commit a fix for that
shortly.
llvm-svn: 300148
Summary:
__compressed_pair takes and passes it's constructor arguments by value. This causes arguments to be moved 3 times instead of once. This patch addresses that issue and fixes `constexpr` on the constructors.
I would rather have this fix than D27564, and I'm fairly confident it's not ABI breaking but I'm not 100% sure.
I prefer this solution because it removes a lot of code and makes the implementation *much* smaller.
Reviewers: mclow.lists, K-ballo
Reviewed By: K-ballo
Subscribers: K-ballo, cfe-commits
Differential Revision: https://reviews.llvm.org/D27565
llvm-svn: 300140
For reference deleter types the const qualifier on the return type
of get_deleter() should be ignored, and a non-const deleter should
be returned.
This patch fixes a bug where "const deleter_type&" is incorrectly
formed.
llvm-svn: 300121
The inline function definition ABI macro is gated on COFF dllexport
semantics, so it's more appropriate to mark it with the object file
format macro rather than the generic _WIN32 macro. We now have no uses
of _WIN32 apart from those used to define the other Windows macros :)
Clarify the ABI macro comment and make the object file format check
exhaustive while I'm here.
llvm-svn: 300097
LLVM dropped support for Visual Studio versions older than 2015 quite
some time ago, so I consider it safe to drop libc++'s support for older
CRTs. The CRT in Visual Studio 2015 provides a lot of previously missing
functions, so targeting it requires less special casing.
Differential Revision: https://reviews.llvm.org/D31798
llvm-svn: 299743
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: 299734
We're using -nodefaultlibs to avoid the dependency on C++ library
when using check_cxx_compiler_flag, and as such we cannot use
check_cxx_compiler_flag to check the availability of -nodefaultlibs
itself.
llvm-svn: 299711
Can be used as such:
$ python /path/to/lit.py -sv /path/to/llvm/build/projects/libcxx/test/ \
--param=use_system_cxx_lib=true \
--param=executor='SSHExecutor("remote.domain", "username")'
llvm-svn: 299607
When compiler-rt is requested, we should attempt to link compiler-rt
builtins library rather than gcc_s.
Differential Revision: https://reviews.llvm.org/D31617
llvm-svn: 299599
Method specializations don't get exported even if there's an exported
extern template instantiation on Windows. Explicitly mark the methods
for export. They're already exported on Linux and Darwin, so there's no
ABI change on those platforms.
llvm-svn: 299348
This is effectively a partial revert of r278356, which started inlining
basic_string::__init. Even if we want to help the compiler along with
an inlinehint, we shouldn't hamstring it by forcing it to inline all the
time.
Libc++ uses always_inline widely as a limit-the-ABI-hack, but since
__init is already on the dylib boundary, it makes no sense here and just
harms the debugging experience at -O0.
rdar://problem/31013102
llvm-svn: 299290
r145698 introduced _LIBCPP_HAS_NO_STRONG_ENUMS by copy-pasting the
__has_feature check from objc_arc_weak/_LIBCPP_HAS_OBJC_ARC_WEAK, and
accidentally started defining _LIBCPP_HAS_NO_STRONG_ENUMS whenever
__has_feature(objc_arc_weak). This is totally bogus, and means that
Libc++ thinks Objective-C++ compilations with -fobjc-arc don't have
strong enums.
Delete the accidental line.
I thought about adding a test, but it would be entirely duplicative of
the patch (if has-feature strong enums, check that has-no-strong-enums
is not defined).
llvm-svn: 299236
Summary:
mingw64 has lots of default libs that libc++ and its test programs
should link against.
With this patch, cmake now runs successfully with GCC on Windows.
Reviewers: mati865, EricWF
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D31518
llvm-svn: 299144
Both libc++ and libc++abi export a weak definition of operator
new/delete. On Darwin, this can often cause dirty __DATA in the
shared cache when having to switch from one to the other. Instead,
libc++ should reexport libc++abi's implementation of these symbols.
Patch by: Ted Kremenek <kremenek@apple.com>
Differential Revision: https://reviews.llvm.org/D30765
llvm-svn: 299054
As we're trying to setup testing / bots for all shipping version of libc++
on macOS/iOS, we'll need to be able to pass a path to where to find the
dylib for each previous version of the OS.
Differential Revision: https://reviews.llvm.org/D31486
llvm-svn: 299053
Summary:
bad_function_call is currently an empty class, so any object files using
that class will end up with their own copy of its typeinfo, typeinfo
name and vtable, leading to unnecessary duplication that has to be
resolved by the dynamic linker. Instead, give bad_function_call a key
function and put a definition for that key function in libc++ itself, to
centralize the typeinfo and vtable.
This is consistent with the behavior for other exception classes. The
key functions are defined in libc++ rather than libc++abi since the
class is defined in the libc++ versioning namespace, so ABI
compatibility with libstdc++ is not a concern.
Guard this change behind an ABI macro, since it isn't backwards
compatible (i.e., clients built against the new libc++ headers wouldn't
be able to run against an older libc++ library).
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D27387
llvm-svn: 298937
Summary:
By manipulating a local variable in the loop, when the loop can
be optimized away (due to no non-trivial destructors), this lets
it be fully optimized away and we modify the __end_ separately.
This results in a substantial improvement in the generated code.
Prior to this change, this would be generated (on x86_64):
movq (%rdi), %rdx
movq 8(%rdi), %rcx
cmpq %rdx, %rcx
je LBB2_2
leaq -12(%rcx), %rax
subq %rdx, %rax
movabsq $-6148914691236517205, %rdx ## imm = 0xAAAAAAAAAAAAAAAB
mulq %rdx
shrq $3, %rdx
notq %rdx
leaq (%rdx,%rdx,2), %rax
leaq (%rcx,%rax,4), %rax
movq %rax, 8(%rdi)
And after:
movq (%rdi), %rax
movq %rax, 8(%rdi)
This brings this in line with what other implementations do.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25241
llvm-svn: 298601
Summary: This is my attempt to work around the C1XX bug described to me by @BillyONeal.
Reviewers: BillyONeal, STL_MSFT, CaseyCarter
Reviewed By: BillyONeal
Subscribers: cfe-commits, BillyONeal
Differential Revision: https://reviews.llvm.org/D31260
llvm-svn: 298554
Eric Fiselier