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
llvm-svn: 307357
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.
llvm-svn: 307118
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.
llvm-svn: 307117
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
llvm-svn: 306859
Summary:
This reference to lit.util.capture is functionally identical to
subprocess.check_output, so this change switches to call the library routine
directly.
Reviewers: mzolotukhin, EricWF
Reviewed By: mzolotukhin
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D34841
llvm-svn: 306755
The string literal operators have implicit instantiations of
basic_string<char> and basic_string<wchar>, which prevent the dllimport
on the subsequent explicit instantiation declarations from having an
effect. Hoisting the explicit instantiations above the implicit ones
fixes the issue.
I think it's pretty unfortunate that the ordering has such an effect,
and I'd fixed the same issue for dllexport in r288682. dllimport is more
complicated from a codegen perspective, however, and clang's behavior of
ignoring the dllimport when there's a previous implicit instantiation is
consistent with cl, so changing the order is our only recourse.
llvm-svn: 306632
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
llvm-svn: 306310
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.
llvm-svn: 305854
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.
llvm-svn: 305843
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
llvm-svn: 305668
Most of filesystem/path.cpp uses string_view_t. This fixes the two spots
that use string_view directly.
https://reviews.llvm.org/D34332
llvm-svn: 305661
Fix an off-by-one in r302172, which triggered building local versions of
the iostreams when deploying to `<= macOS 10.9`, when it should have
been `< macOS 10.9`. 10.9 had the dylib support.
This defines `_LIBCPP_AVAILABILITY_NO_STREAMS_EXTERN_TEMPLATE` less
often, reducing code size for users with deployment targets of exactly
macOS 10.9 or iOS 7.0.
rdar://problem/32233981
llvm-svn: 305649
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.
llvm-svn: 305539
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.
llvm-svn: 305536
Previously the explicit instantiation for this was in locale.cpp,
but that didn't make much sense. This patch creates a new vector.cpp
source file to contain the explicit instantiation.
llvm-svn: 305442
The function num_get<_CharT>::stage2_int_prep makes unnecessary copy of src
into atoms when char_type is char. This can be avoided by creating
a switch on type and just returning __src when char_type is char.
Added the test case to demonstrate performance improvement.
In order to avoid ABI incompatibilities, the changes are guarded
with a macro _LIBCPP_ABI_OPTIMIZED_LOCALE_NUM_GET
Differential Revision: https://reviews.llvm.org/D30268
Reviewed by: EricWF
llvm-svn: 305427
Newlib 2.5 added the locale management functions, so it should not
include __nop_local_mgmt.h. This change adds proper guard around that
include statement.
For newlib 2.4, some releases contain these functions and some don't,
and they all have the same version numbers. This patch will work
properly with the initial "2.4.0" release which does not include these
functions and require __nop_local_mgmt.h.
This has been tested against newlib 2.2 and 2.5, and also sanity
checks against other different version numbers.
Patch by Martin J. O'Riordan and Walter Lee
Differential Revision: https://reviews.llvm.org/D32146
llvm-svn: 305394
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.
llvm-svn: 305000
Duncan P. N. Exon Smith