This patch adds end-to-end/breathing tests for coroutines
into libc++. The tests aren't specifically to test libc++ requirements
but instead are intented to ensure coroutines are working fine in general.
Although libc++ isn't exactly the most correct place for these tests
to live, there is one major advantage. The libc++ test suite is also
used by MSVC and by adding the tests here it ensures they will be
run against all currently available coroutine implementations.
llvm-svn: 304101
Clang supports coroutines in all dialects; Therefore libc++ should too,
otherwise the Clang extension is unusable.
I'm not convinced extending support to C++03 is a feasible long term
plan, since as the library grows to offer things like generators it
will be come increasingly difficult to limit the implementation to C++03.
However for the time being supporting C++03 isn't a big deal.
llvm-svn: 303963
Clang started providing -fcoroutines and defining __cpp_coroutines
way before it implemented the __builtin_coro_foo functions. This
means that simply checking if __cpp_coroutines is not a sufficient
way of detecting the actual feature.
This patch implements _LIBCPP_HAS_NO_COROUTINES which implements
a slightly more complex feature check. Specifically it requires
__cpp_coroutines >= 201703L, which only holds for Clang 5.0 built
after 2017/05/24.
llvm-svn: 303956
The tests were previously guarded by #if defined(_LIBCPP_VER) || defined(_MSVC_STL_VER),
which is both incorrect (e.g. _LIBCPP_VERSION) and unneeded. Although the tests are
technically non-standard (yet) they are supported by both libc++ and MSVC's STL.
libstdc++ doesn't regularly use the test suite so I'm not concerned about guarding these
tests for them.
llvm-svn: 303953
The original issues were caused because <experimental/coroutine>
didn't correctly #ifdef out enough of the header, which caused incomplete
types to be used.
This patch fixes the `#if defined(__cpp_coroutines)` guard and re-adds
the headers to the module map.
It also uglifies some incorrectly non-reserved names.
llvm-svn: 303936
This patch updates the promise() member to match the current spec.
Specifically it removes the non-const overload and make the return
type of the const overload non-const.
This patch also makes the ASSERT_NOT_NOEXCEPT tests libc++ specific,
since other implementations may be free to strengthen the specification.
llvm-svn: 303895
VSO#391542 "Types can't be convertible to nullptr_t"
Also put internal bug numbers on the workarounds in test_workarounds.h for correlation.
Differential Revision: https://reviews.llvm.org/D33290
llvm-svn: 303889
This C++17 Core Language feature isn't necessary when testing std::byte.
It's a minor convenience, but it limits test coverage to very new compilers.
This part activates the tests for more compilers.
llvm-svn: 302945
This C++17 Core Language feature isn't necessary when testing std::byte.
It's a minor convenience, but it limits test coverage to very new compilers.
This part changes the code.
Fixes D32386.
llvm-svn: 302944
This patch cleans up a number of issues reported by STL, including:
1) Fix duplicate is_convertible test.
2) Move non-standard reference_wrapper tests under test/libcxx
3) Fix assumption that sizeof(wchar_t) == 32 in the codecvt and
wstring_convert tests.
llvm-svn: 302870
This patch removes the clear() member from <string_view>. The
modifier was removed from the TS before it ever landed in the standard.
There is no reason libc++ should be providing this method.
llvm-svn: 302869
This patch attempts to make lookup_classname.pass.cpp usable against
other STL implementations by guarding the use of __regex_word. That being
said it seems likely that the test is still non-conforming due to how
libc++ handles the "w" character class.
llvm-svn: 302859
Some MinGW configurations use WinPThread instead of the native
threading interfaces. When this happens libc++ doesn't build because
it tries to use the wrong threading API.
This patch attempts to correctly detect and enable pthreads; Selecting
them when __MINGW32__ is defined and __has_include(<pthread.h>) is true.
I'm not sure if this works correctly 100% of the time but it seemed
like the most correct approach available.
llvm-svn: 302734
This patch follows up on feedback received in the review for
D32988. Specifically that libc++ should not mess with the
__builtin namespace, and that libc++ should use __popcnt to implement
__pop_count under MSVC.
llvm-svn: 302731
Summary:
This patch refactors and tries to remove as much of the Windows support headers as possible. This is needed because they currently introduce super weird include cycles and dependencies between STL and libc headers.
The changes in this patch are:
* remove `support/win32/support.h` completely. The required parts have either been moved into `support/win32/msvc_support.h` (for `MSVC` only helpers not needed by Clang), or directly into their respective `foo.h` headers.
* Combine `locale_win32.h` and `locale_mgmt_win32.h` into a single headers, this header should only be included within `__locale` or `locale` to avoid include cycles.
* Remove the unneeded parts of `limits_win32.h` and re-name it to `limits_msvc_win32.h` since it's only needed by Clang.
I've tested this patch using Clang on Windows, but I suspect it might technically regress our non-existent support for MSVC. Is somebody able to double check?
This refactor is needed to support upcoming fixes to `<locale>` on Windows.
Reviewers: bcraig, rmaprath, compnerd, EricWF
Reviewed By: EricWF
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D32988
llvm-svn: 302727
Clang 5.0 implements these changes here: 87cd035326
MSVC++ will implement these changes in the first toolset update to 2017.
Differential Revision: https://reviews.llvm.org/D33021
llvm-svn: 302710
Summary:
This patch fixes bugs.llvm.org/PR32979.
[util.smartptr.shared.const] says:
> In the constructor definitions below, enables shared_from_this with p, for a pointer p of type Y*, means
> that if Y has an unambiguous and accessible base class that is a specialization of enable_shared_from_-
> this.
This means that libc++ needs to respect the access specifier of the base class, and not attempt to construct
and enabled_shared_from_this base if it is private. However access specifiers don't affect overload resolution
so our current implementation will attempt to construct the private base.
This patch uses SFINAE to correctly detect if the shared_ptr input has an accessible enable_shared_from_this
base class.
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33033
llvm-svn: 302709
This change works around a couple of bugs:
1. EDG doesn't like explicit constexpr in a derived class. This program:
struct Base {};
struct Derived : Base {
constexpr Derived() = default;
};
triggers "error: defaulted default constructor cannot be constexpr."
2. C1XX with /Za has no idea which constructor needs to be valid for copy elision.
The change also conditionally disables parts of the msvc_stdlib_force_include.hpp header that conflict with external configuration when _LIBCXX_IN_DEVCRT is defined.
Differential Revision: https://reviews.llvm.org/D32778
llvm-svn: 302707
I'm really lazy and the old name for the helper script
killed 2 letter tab completion for the include directory.
This patch renames it to avoid that problem and enable
lazyness.
llvm-svn: 302619
With the amount of work happening on Windows we should
have a MinGW bot to make sure we don't regress that functionality.
Currently it doesn't build :-(
llvm-svn: 302614
Previously, the force includes would complain about a missing _DEBUG symbol.
Now we dump macros before adding the force includes to the command line.
Now with proper newlines.
llvm-svn: 302497
This patch fixes the test failures and unexpected passes that occur
when testing against GCC 7. Specifically:
* don't mark __gcd as always inline because it's a recursive function. GCC diagnoses this.
* don't XFAIL the aligned allocation tests. GCC 7 supports them but not the -faligned-allocation option.
* Work around gcc.gnu.org/PR78489 in variants constructors.
llvm-svn: 302488
Previously <locale> used std::unique_ptr<remove_ptr<locale_t>, locale-mgmt-function>
as a scope guard for (A) creating new locales, and (B) setting the thread specific locale
in RAII safe manner.
However using unique_ptr has some problems, first it requires that locale_t is a pointer
type, which may not be the case (Windows will need a non-pointer locale_t type that emulates _locale_t).
The second problem is that users of the guards had to supply the locale management function to the custom
deleter at every call site. However these locale management functions don't exist natively Windows, making
a good Windows implementation of locale more difficult.
This patch creates distinct and simply RAII guards that replace unique_ptr. These guards handle calling
the correct locale management function so that callers don't have too. This simplification will
aid in upcoming Windows fixes.
llvm-svn: 302474
In T_size_size.pass, there is an explicit template argument to std::min to ask
for unsigned, to avoid type deduction errors. However, C1XX' warnings still
hate this use, because a 64 bit value (a size_t) is being passed to a function
accepting an unsigned (a 32 bit value).
Instead, change the tests to pass around std::size_t instances, and explicitly
narrow when constructing the string type under test. This also allows
removal of explicit template arguments to std::min.
llvm-svn: 302473
lcm.pass.cpp:
19: Update headers to that actually used in the test.
41: test0 was triggering narrowing warnings for all callers, because the
inputs were always ints, but some of the explicit template arguments were
smaller than that. Instead, have this function accept ints and static_cast
explicitly to the types we want before calling std::lcm.
47: Replace unnecessary ternary.
55: Use foo_t instead of typename foo<>::type
111/116: intX_t were not std::qualified but only <cfoo> headers were included.
141: C1XX has a bug where it interprets 2147483648 as unsigned int. Then the
negation trips "negation of unsigned value, result still unsigned" warnings.
Perma-workaround this issue by saying INT_MIN, which better documents the
intended behavior and avoids triggering warnings on C1XX.
gcd.pass.cpp:
Same changes as lcm.pass.cpp but for GCD.
llvm-svn: 302472
Previously, the force includes would complain about a missing _DEBUG symbol.
Now we dump macros before adding the force includes to the command line.
llvm-svn: 302421
Summary:
This patch implements exception_ptr on Windows using the `__ExceptionPtrFoo` functions provided by MSVC.
The `__ExceptionPtrFoo` functions are defined inside the C++ standard library, `msvcprt`, which is unfortunate because it requires libc++ to link to the MSVC STL. However this doesn't seem to cause any immediate problems. However to be safe I kept all usages within the libc++ dylib so that user programs wouldn't have to link to MSVCPRT as well.
Note there are still 2 outstanding exception_ptr/nested_exception test failures.
* `current_exception.pass.cpp` needs to be rewritten for the Windows exception_ptr semantics which copy the exception every time.
* `rethrow_if_nested.pass.cpp` need investigation. It hits a stack overflow, likely from recursion.
This patch also gets most of the `<future>` tests passing as well.
Reviewers: mclow.lists, compnerd, bcraig, rmaprath, majnemer, BillyONeal, STL_MSFT
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D32927
llvm-svn: 302393
Libc++ doesn't provide its own definitions of new/delete on Windows,
instead using the versions provided by VCRuntime. However VCRuntime
does not yet implement aligned new/delete so these tests fail.
It might be possible for libc++ to provide its own definitions only
for aligned new/delete as long as MSVC doesn't provide it. However
before this can be done libc++ needs to figure out how to implement
std::get_new_handler.
llvm-svn: 302384
This patch fixes test failures that occur on Windows because
the tests attempt to generate two distinct temp file names but
get the same name both time.
The fix for this is to create the first temp file before requesting
a second temporary file name. This ensures that the second name
will be unique.
llvm-svn: 302382
On Windows the function template `template <class T> void test()` has
the same mangled name when instantiated with the distinct types `void()`
and `void() noexcept`. When this occurs Clang emits an error. This error
was causing two type-traits tests to fail.
However this can be worked around by using class templates instead of
function templates, which is what this patch does to fix the errors.
llvm-svn: 302380
Summary:
In https://bugs.freebsd.org/207918, Daniel McRobb describes how using
std::showbase with ostreams can cause truncation of unsigned long long
when output format is octal. In fact, this can even happen with
unsigned int and unsigned long.
To ensure this does not happen, add one additional character to the
do_put buffers if std::showbase is on. Also add a test case.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D32670
llvm-svn: 302362
The ERROR_TIMEDOUT returned by the Windows API does not
have the same value as ETIMEDOUT. This caused condition_variable
to return timeouts as unknown errors.
llvm-svn: 302297
Libc++ is used as a system library on macOS and iOS (amongst others). In order
for users to be able to compile a binary that is intended to be deployed to an
older version of the platform, clang provides the
availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_
that can be placed on declarations to describe the lifecycle of a symbol in the
library.
See docs/DesignDocs/AvailabilityMarkup.rst for more information.
Differential Revision: https://reviews.llvm.org/D31739
llvm-svn: 302172
_HAS_CXX17 indicates whether MSVC's STL is in C++17 mode.
In MSVC there's a distinction between CRT headers like stdlib.h and STL headers
like cstdlib. Only the STL headers drag in yvals.h, our internal STL-wide header
that defines internal macros like _HAS_CXX17.
_HAS_CXX17 is an MSVC STL library macro, unconditionally defined. We centralize
everything on this, because we have to ask different questions to determine
whether C1XX, EDG, or Clang is in 14 or 17 mode, and we additionally permit
users to override the detection in one way (it's okay to ask for 17 from the
compiler, but only 14 from the libs, at least for the moment; only noexcept
in the type system will give us a headache).
As this header is for testing MSVC's STL, we can assume _HAS_CXX17 is defined.
Fixes D32726.
llvm-svn: 302104
r296685 started adding the test/ subdirectory even when
LIBCXX_INCLUDE_TESTS=OFF. This is great for testing libcxx standalone,
but it also breaks the build when the test/ subdirectory is removed
(and our submission system strips all test/ directories).
This patch updates the logic to check for test/ before adding it.
rdar://problem/31931366
llvm-svn: 302095
Summary: Seemed to have been overlooked in D24028.
This bug was found and brought to my attention by Paul Wankadia.
Reviewers: kubamracek, EricWF, dvyukov
Differential Revision: https://reviews.llvm.org/D32402
llvm-svn: 301132
For std::isinf, the standard requires effectively calling isinf as
double from Libc for integral types. But integral types are never
infinite; we don't need to call Libc to return false.
Also short-circuit other functions where Libc won't have interesting
answers: signbit, fpclassify, isfinite, isnan, and isnormal.
I added correctness tests for integral types since we're no longer
deferring to Libc.
In review it was pointed out that in future revisions of the C++
standard we may add more types to std::is_arithmetic (e.g.,
std::is_fixed_point). I'll leave it to a future commit to hack this to
allow using math functions on those. We'll need to change things like
__libcpp_fpclassify anyway, so I'm not sure anything here would really
be future-proof.
https://reviews.llvm.org/D31561
rdar://problem/31361223
llvm-svn: 301060
* Cover optional's emplace-from-initializer_list overload
* Verify that any::emplace and optional::emplace return a reference to the correct type even for throwing cases.
Differential Revision: https://reviews.llvm.org/D32106
llvm-svn: 301055
This patch XFAIL's a number of tests under test/libcxx when on Windows.
These failures need more investigation or patches to either Clang or libc++
but for now we don't want them to prevent the bot from going green.
llvm-svn: 300941
Summary:
libc++abi is never the right option for LIBCXX_TARGETING_MSVC, since it
targets the Itanium ABI, whereas MSVC uses the Microsoft ABI. Make the
default ABI be vcruntime when targeting MSVC even if libc++abi is
present in the tree.
Differential Revision: https://reviews.llvm.org/D32320
llvm-svn: 300921
Previously the ATOMIC_<TYPE>_LOCK_FREE macros were implemented
using __GCC_ATOMIC_<TYPE>_LOCK_FREE but GCC specific macros
are defined when -fms-compatibility is specified.
To avoid this Libc++ now tries to use the newly added
__CLANG_ATOMIC_<TYPE>_LOCK_FREE macros instead, and only falls
back to the GCC versions when the Clang ones aren't available.
llvm-svn: 300920
Previously both the static version of libc++ and the
import library for the DLL had the same name, 'c++.lib'.
This patch renames the static library on Windows to be `libc++.lib`
so it no longer conflicts. This naming convention is consistent with
other windows libraries.
llvm-svn: 300817
I'm currently trying to get a libc++ Windows builder working on appveyor.
This patch adds the configuration file needed to build libc++ on Appveyor.
Details of where the buildbot can be found will come later
llvm-svn: 300786
_LIBCPP_ABI_MICROSOFT is more appropriate to use here, since the
conditionals are controlling Microsoft mangling. It wasn't used
originally since it didn't exist at the time.
llvm-svn: 300743
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
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
Eric Fiselier