This improves readability and (theoretically) improves portability,
as _Ugly names are reserved.
This performs additional de-uglification, so all of these tests
follow the example of iterator.traits/empty.pass.cpp.
llvm-svn: 310761
This makes them consistent (many comments already used uppercase).
The special REQUIRES, UNSUPPORTED, and XFAIL comments are excluded from this change.
llvm-svn: 309468
Creating a function pointer with proper parameters pointing to std::next() or std::prev() should work.
This change moves the invented paramater for enable_if over to the return type to resolve this QoI issue.
Patch by Jason Liu.
Differential Revision: https://reviews.llvm.org/D34649
llvm-svn: 308932
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
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
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
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
Stephan T. Lavavej