r283051 added some functions to cmath (in namespace std) that have the
same name as functions in math.h (in the global namespace). Clang's
limited support for `-fdelayed-template-parsing` chokes on this. Rename
the ones in `cmath` and their uses in `complex` and the test.
rdar://problem/32848355
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307357 91177308-0d34-0410-b5e6-96231b3b80d8
In order for IDE's like CLion to correctly parse and highlight the tests
it needs to know roughly how to build them. This patch adds a dummy CMake target
for each/all of the .pass.cpp tests in the test suite to solve this problem.
The target is only created when LIBCXX_CONFIGURE_IDE=ON, so it shouldn't affect
most users.
Originally I wasn't sure that this change deserved to live upstream, but it's
quite frustrating to edit libc++ tests using CLion or Visual Studio without it,
in particular the filesystem tests which rely heavily on macros. Even though the change
should have no effect on non-IDE users/configurations I decided to commit it upstream
with the hopes it will benefit somebody other than me.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307118 91177308-0d34-0410-b5e6-96231b3b80d8
This patch speculatively implements the PR for LWG 2937, which fixes
two issues with equivalent.
(1) It makes equivalent("dne", "exists") an error. Previously only
equivalent("dne", "dne") was an error and the former case was not (it returned false).
Now equivalent reports an error when either input doesn't exist.
(2) It makes equivalent(p1, p2) well-formed when `is_other(p1) && is_other(p2)`.
Previously this was an error, but there is seemingly no reason why it should be on POSIX system.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307117 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r306310.
r306310 causes clang to reject a call to an aligned allocation or
deallocation function if it is not implemented in the standard library
of the deployment target. This is not the desired behavior when users
have defined their own aligned functions.
rdar://problem/32664169
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@306859 91177308-0d34-0410-b5e6-96231b3b80d8
attribute.
This is needed because older versions of libc++ do not have these
operators. If users target an older deployment target and try to compile
programs in which these operators are explicitly called, the compiler
will complain.
The following is the list of minimum deployment targets for the four
OSes:
macosx: 10.13
ios: 11.0
tvos: 11.0
watchos: 4.0
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D34556
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@306310 91177308-0d34-0410-b5e6-96231b3b80d8
Clang and C1XX both complain about mismatched class/struct, but libc++ and MSVC's STL
differ on what they use for tuple_element/tuple_size, so there's no way to win here.
I'm reverting this part of my previous change. In the future, I'll have to suppress
the warning for one compiler or the other.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305854 91177308-0d34-0410-b5e6-96231b3b80d8
Style/paranoia: 42.1 doesn't have an exact binary representation. Although this doesn't
cause failures, it makes me uncomfortable, so I'm changing it to 42.5.
C1XX rightly warns about unreferenced variables. Adding tests for their values
makes C1XX happy and improves test coverage.
C1XX (somewhat obnoxiously) warns about seeing a struct specialized as a class.
Although the Standard doesn't care, saying struct consistently is better.
(The Standard itself is still inconsistent about whether to depict tuple_element
and tuple_size as structs or classes.)
Fixes D33953.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305843 91177308-0d34-0410-b5e6-96231b3b80d8
Remarks: This function shall not participate in overload resolution unless
`is_same_v<decay_t<T>, variant>` is false, unless `decay_t<T>` is
neither a specialization of `in_place_type_t` nor a specialization of
`in_place_index_t`, unless `is_constructible_v<Tj, T>` is true, and
unless the expression `FUN(std::forward<T>(t))` (with `FUN` being the
above-mentioned set of imaginary functions) is well formed.
Depends on D34111.
Reviewers: EricWF, K-ballo
Reviewed By: EricWF
Subscribers: fhahn
Differential Revision: https://reviews.llvm.org/D34112
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305668 91177308-0d34-0410-b5e6-96231b3b80d8
C99 at least. C89 still fails due to the use of block comments.
NOTE: Having libc++ on the include path when compiling C is not
recommended or ever really supported. However it happens often
enough that this change is warrented.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305539 91177308-0d34-0410-b5e6-96231b3b80d8
It seems conceivable that a user would need to get a coroutine handle
having only a const reference to the promise_type, for example from
within a const member function of the promise.
This patch allows that use case. A coroutine_handle<const T> can be used
in essentially the same way a coroutine_handle<T>, ie to start and destroy
the coroutine. The constness of the promise doesn't/shouldn't propagate
to the handle.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305536 91177308-0d34-0410-b5e6-96231b3b80d8
locale.codecvt.byname/ctor_char.pass.cpp:
This test used to use "en_US" as a plain string instead of using platform_support.
Need to fix this because MS STL expects "en-US" instead.
platform_support.h:
These are the legacy Windows locale names. Should use IETF tags instead.
I've also added en_US, since a test was using that as a locale string as well.
msvc_stdlib_force_include.hpp:
Remove _MSVC_STL_VER. The libraries will directly define _MSVC_STL_VERSION in the future.
Fixes D29351.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305000 91177308-0d34-0410-b5e6-96231b3b80d8
On Bionic PTHREAD_MUTEX_INITIALIZER contains the expression "<enum-type> & <integer-type>",
which causes ADL to perform name lookup for operator&. During this lookup Clang decides
that it requires the default member initializer for std::mutex while defining the DMI
for std::mutex::__m_.
If I'm not mistaken this is caused by the explicit noexcept declaration on the defaulted
constructor.
This patch removes the explicit noexcept and instead allows the compiler to declare
the default constructor implicitly noexcept. It also adds a static_assert to ensure
that happens.
Unfortunatly because it's not easy to change the value of _LIBCPP_MUTEX_INITIALIZER
for a single test there is no good way to test this patch.
The Clang behavior causing the trouble here was introduced in r287713, which first
appears in the 4.0 release.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304942 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
- Removed the move-constructibe requirement from copy-assignable.
- Updated `__assign_alt` such that we direct initialize if
`_Tp` can be `nothrow`-constructible from `_Arg`, or `_Tp`'s
move construction can throw. Otherwise, construct a temporary and move it.
- Updated the tests to remove the pre-LWG2904 path.
Depends on D32671.
Reviewers: EricWF, CaseyCarter
Reviewed By: EricWF
Differential Revision: https://reviews.llvm.org/D33965
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304891 91177308-0d34-0410-b5e6-96231b3b80d8
This macro will instruct MSVC's STL to not warn about features that are deprecated in C++17,
as libcxx tests those features and uses them elsewhere.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304765 91177308-0d34-0410-b5e6-96231b3b80d8
Was VSO#109062. This bug was filed *4 years ago*. I submitted a workaround to enable the scoped_allocator_adaptor tests to pass. Bug fixed a week and a half later. This was either a waste of my time, or I've discovered that libc++ has magical bugfix-inducing powers. My money's on the latter.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304730 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r304462, thereby re-enabling two tests under ubsan.
We expect these tests to pass now that PR33271 is fixed.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304580 91177308-0d34-0410-b5e6-96231b3b80d8
