Only the [cmp.alg] part (for `comparison_meow_fallback` CPOs) in the
paper required changes. Other parts merely fixed preconditions of some
standard library functions.
I strongly feel that P2167R3 should be a DR despite that it is not a DR
officially: CPOs -> C++20; remain parts -> C++98/11 (except that
_`boolean-testable`_ should be transformed into the original
_BooleanTestable_ requirements in the old resolution of LWG2114).
Note that P2167R3 damaged the resolution of LWG3465: the type of `F < E`
was left underconstrained. I've tried to submit an LWG issue for this,
which is now LWG4157.
Drive-by change:
- enable some test coverages in `compare_strong_order_fallback.pass.cpp`
when `TEST_LONG_DOUBLE_IS_DOUBLE`, following up #106742Closes#105241.
This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.
Issue #43670 describes a situation where the following comparison will
issue a warning when -Wzero-as-null-pointer-constant is enabled:
#include <compare>
auto b = (1 <=> 2) < 0;
This code uses operator<(strong_ordering, Unspecified), which is
specified by the Standard to only work with a literal 0. In the library,
this is achieved by constructing Unspecified from a pointer, which works
but has the downside of triggering the warning.
This patch uses an alternative implementation where we require that the
operator is used exactly with an int of value 0 (known at compile-time),
however that value can technically be an expression like `1 - 1`, which
makes us a bit less strict than what's specified in the Standard.
Fixes#43670
We pretty consistently don't define those cause they are not needed,
and it removes the potential pitfall to think that these tests are
being run. This doesn't touch .compile.fail.cpp tests since those
should be replaced by .verify.cpp tests anyway, and there would be
a lot to fix up.
As a fly-by, I also fixed a bit of formatting, removed a few unused
includes and made some very minor, clearly NFC refactorings such as
in allocator.traits/allocator.traits.members/allocate.verify.cpp where
the old test basically made no sense the way it was written.
Differential Revision: https://reviews.llvm.org/D146236
This target (as well as 32-bit ARM Android) have sizeof(long double)
equal to sizeof(double).
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D137135
The corresponding _LIBCPP_HAS_NO_SPACESHIP_OPERATOR macro was already
removed in commit c0f87e8382
Differential Revision: https://reviews.llvm.org/D131215
All supported compilers that support C++20 now support concepts. So, remove
`_LIB_LIBCPP_HAS_NO_CONCEPTS` in favor of `_LIBCPP_STD_VER > 17`. Similarly in
the tests, remove `// UNSUPPORTED: libcpp-no-concepts`.
Differential Revision: https://reviews.llvm.org/D121528
Now that we've branched for the LLVM 14 release, our support window
moves to clang-13 and clang-14. Similarly, AppleClang 13 has been
released for some time now, so that should be the oldest compiler
we support, per our policy.
A possible follow-up would be to remove _LIBCPP_HAS_NO_CONCEPTS, since
I don't think we support any compiler that doesn't support concepts
anymore.
Differential Revision: https://reviews.llvm.org/D118831
This avoids using an libc++ internal macro in our tests. This version
doesn't depend on the internal macro but redefines it.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D119460
The tests for these are just copy-pasted from the tests for std::{strong,weak,partial}_order,
and then I added an extra clause in each (test_2()) to test the stuff that's not just the same
as std::*_order.
This also includes the fix for https://wg21.link/LWG3465 (which falls naturally out of the
"you must write it three times" style, but I've added test cases for it also).
There is an action item here to go back and give good diagnostics for SFINAE failures
in these CPOs. I've filed this as https://github.com/llvm/llvm-project/issues/53456 .
Differential Revision: https://reviews.llvm.org/D111514
This should fix the regressions detected in D117992.
This lands before D117992 to avoid breaking main.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D118056
This does not include `std::compare_*_fallback`; those are coming later.
There's still an open question of how to implement std::strong_order
for `long double`, which has 80 value bits and 48 padding bits on x86-64,
and which is presumably *not* IEEE 754-compliant on PPC64 and so on.
So that part is left unimplemented.
Differential Revision: https://reviews.llvm.org/D110738
Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C++ code),
they certainly have no benefit for files with the .cpp extension.
Discussed in D110794.
Some of these were previously half-implemented in "ordering.h";
now they're all implemented, and tested.
Note that `constexpr` functions are implicitly `inline`, so the
standard wording omits `inline` on these; but Louis and I agree
that that's surprising and it's better to be explicit about it.
Differential Revision: https://reviews.llvm.org/D110515
Implementation of `three_way_comparable` and `three_way_comparable_with` concepts from <compare> header.
Please note that I have temporarily removed `<compare>` header from `<utility>` due to cyclic dependency that prevents using `<concepts>` header in `<compare>` one.
I tried to quickly resolve those issues including applying suggestions from @cjdb and dive deeper by myself but the problem seems more complicated that we thought initially.
I am in progress to prepare the patch with resolving this cyclic dependency between headers but for now I decided to put all that I have to the review to unblock people that depend on that functionality. At first glance the patch with resolving cyclic dependency is not so small (unless I find the way to make it smaller and cleaner) so I don't want to mix everything to one review.
Reviewed By: ldionne, cjdb, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D103478
Due to issues with the detection of the clang-verify feature, these
tests have been skipped in the Windows CI configuration so far.
Differential Revision: https://reviews.llvm.org/D103308
D85051's honeypot solution was a bit too aggressive swallowed up the
comparison types, which made comparing objects of different ordering
types ambiguous.
Depends on D101707.
Differential Revision: https://reviews.llvm.org/D101708
* `operator!=` isn't in the spec
* `<compare>` is designed to work with `operator<=>` so it doesn't
really make sense to have `operator<=>`-less friendly sections.
Depends on D100283.
Differential Revision: https://reviews.llvm.org/D100342
`weak_equality` and `strong_equality` were removed before being
standardised, and need to be removed.
Also adjusts `common_comparison_category` since its test needed
adjusting due to the equality deletions.
Differential Revision: https://reviews.llvm.org/D100283
* Use an empty struct instead of a member pointer to represent this
type, so that we don't actually pass a zero member pointer at runtime.
* Mark the constructor as consteval to ensure that no code is emitted
for it whenever possible.
* Add a honeypot constructor to reject all non-int arguments, so that
the only argument that can arrive at the real constructor is the
literal 0.
This results in better generated code, and rejecting invalid comparisons
against nullptr, 0L, and so on, while also rejecting invalid comparisons
against (1-1) and similar that would be allowed if we required an
integer constant expression with value 0.
Differential Revision: https://reviews.llvm.org/D85051
C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.
This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.
Differential Revision: https://reviews.llvm.org/D80926
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".
Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:
In utils/libcxx/test/config.py add:
self.cxx.compile_flags += ['-ffreestanding']
Run the tests and they all fail.
Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).
Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.
The former was done with The Magic Of Sed.
The later was done with a (not quite correct but decent) clang tool:
https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed
This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.
Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.
<rdar://problem/47754795>
Reviewers: ldionne, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57624
llvm-svn: 353086
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
this patch adds the <compare> header and implements all of it
except for [comp.alg].
As I understand it, the header is needed by the compiler in
when implementing the semantics of operator<=>. For that reason
I feel it's important to land this header early, despite
all compilers lacking support.
llvm-svn: 329460
