The safe mode is in-between the hardened and the debug modes, extending
the checks contained in the hardened mode with certain checks that are
relatively cheap and prevent common sources of errors but aren't
security-critical. Thus, the safe mode trades off some performance for
a wider set of checks, but unlike the debug mode, it can still be used
in production.
Differential Revision: https://reviews.llvm.org/D158823
Make it a multichoice string to closer mirror the CMake variable. This
allows writing `UNSUPPORTED: libcpp-hardening-mode=unchecked` rather
than `UNSUPPORTED: !libcpp-has-hardened-mode && !libcpp-has-debug-mode`.
Differential Revision: https://reviews.llvm.org/D155906
The hardened mode is intended to only include security-critical,
relatively low-overhead checks that are intended to be usable in
production. By default, assertions are excluded from this mode.
Differential Revision: https://reviews.llvm.org/D155866
`_LIBCPP_ENABLE_ASSERTIONS` was used to enable the "safe" mode in
libc++. Libc++ now provides the hardened mode and the debug mode that
replace the safe mode.
For backward compatibility, enabling `_LIBCPP_ENABLE_ASSERTIONS` now
enables the hardened mode. Note that the hardened mode provides
a narrower set of checks than the previous "safe" mode (only
security-critical checks that are performant enough to be used in
production).
Differential Revision: https://reviews.llvm.org/D154997
This patch only adds new configuration knobs -- the actual assertions
will be added in follow-up patches.
Differential Revision: https://reviews.llvm.org/D153902
As reported in https://reviews.llvm.org/D151953#4472195, the std::move
algorithm (and various other functions that relied on it) stopped working
after starting to use `__constexpr_memmove` in its implementation. This
patch fixes the underlying issue in `__constexpr_memmove` and adds tests
for various related algorithms and functions that were not exercising
trivial move-only types.
Differential Revision: https://reviews.llvm.org/D154613
I made sure they all had some expected-error output in them. Many of
these tests would be better implemented as a positive test using SFINAE,
but this is beyond the scope of this patch.
Differential Revision: https://reviews.llvm.org/D153980
This patch reverts the following commits:
015cd317eaed28a923d14a33c9d6739012a688be (add missing HIDE_FROM_ABI)
420a204d52205f1277a8d5df3dbafac6082e02e2 (add _LIBCPP_NO_CFI)
31eeba3f7c0e2ef4a21c07da9326a4ae1a8de7e2 (add __uninitialized_buffer)
It also reverts a small part of b935ab8e747cf52ff12471879460206a9f433eea
which is required to make the stable_partition.pass.cpp test pass on GCC.
Some issues were pointed out in https://reviews.llvm.org/D152208 and
in https://reviews.llvm.org/D154017, so I am reverting this patch
until we have time to weigh the various solutions and get consensus
on the design of the API.
Differential Revision: https://reviews.llvm.org/D154161
This makes __debug_three_way_comp consistent with __debug_less and
in particular gets rid of a potential use-after-move caused by the
use of std::forward. In the previous version of the code, we would
call `__do_compare_assert` after forwarding the arguments into the
comparator, which could end up using the arguments after they've been
moved from.
This also simplifies how we call `__do_compare_assert` by using
`if constexpr` and adds a missing test for proxy iterators in
lexicographical_compare_three_way, which could have found this
issue.
Differential Revision: https://reviews.llvm.org/D152753
Some tests in our test suite are unbelievably slow on GCC due to the
use of the always_inline attribute. See [1] for more details.
This patch introduces the GCC-ALWAYS_INLINE-FIXME lit feature to
disable tests that are plagued by that issue. At the same time, it
moves several existing tests from ad-hoc `UNSUPPORTED: gcc-12` markup
to the new GCC-ALWAYS_INLINE-FIXME feature, and marks the slowest tests
reported by the CI as `UNSUPPORTED: GCC-ALWAYS_INLINE-FIXME`.
[1]: https://discourse.llvm.org/t/rfc-stop-supporting-extern-instantiations-with-gcc/71277/1
Differential Revision: https://reviews.llvm.org/D152736
An issue with `operator()` was found during the implementation of https://reviews.llvm.org/D132268.
This patch aims to resolve the issues by updating the operator to use perfect forwarding.
The original motivation for `three_way_comp_ref_type` is given in: https://reviews.llvm.org/D131395
`three_way_comp_ref_type`'s implementation is inspired by `comp_ref_type`, which has two overloads:
```
template <class _Tp, class _Up>
bool operator()(const _Tp& __x, const _Up& __y);
template <class _Tp, class _Up>
bool operator()(_Tp& __x, _Up& __y);
```
`__debug_three_way_comp` is missing the first overload and also declares the typealias`_three_way_comp_ref_type ` incorrectly.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D150188
This also removes some tests which we have grouped together into robust_from_*.pass.cpp tests.
Specifically, checking that
- `ranges::dangling` is returned is done in `libcxx/test/std/algorithms/ranges_robust_against_dangling.pass.cpp`
- `std::invoke` is used is done in `libcxx/test/std/algorithms/ranges_robust_against_omitting_invoke.pass.cpp`.
- implicit conversion to bool works is done in `libcxx/test/std/algorithms/ranges_robust_against_nonbool_predicates.pass.cpp`
Checking the comparison order is invalid because the `operator==` isn't symmetric.
Checking what the exact type of `operator==` is, is invalid because comparing the same object has to yield the same results if the objects are not modified.
Reviewed By: ldionne, #libc
Spies: EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D150588
This removes the need for a custom libc++ build to have a basic set of PSTL algorithms.
Reviewed By: ldionne, #libc
Spies: miyuki, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D149624
Instead of writing something like `XFAIL: use_system_cxx_lib && target=...`
to XFAIL back-deployment tests, introduce named Lit features like
`availability-shared_mutex-missing` to represent those. This makes the
XFAIL annotations leaner, and solves the problem of XFAIL comments
potentially getting out of sync. This would also make it easier for
another vendor to add their own annotations to the test suite by simply
changing how the feature is defined for their OS releases, instead
of having to modify hundreds of tests to add repetitive annotations.
This doesn't touch *all* annotations -- only annotations that were widely
duplicated are given named features (e.g. when filesystem or shared_mutex
were introduced). I still think it probably doesn't make sense to have a
named feature for every single fix we make to the dylib.
This is in essence a revert of 2659663, but since then the test suite
has changed significantly. Back when I did 2659663, the configuration
files we have for the test suite right now were being bootstrapped and
it wasn't clear how to provide these features for back-deployment in
that context. Since then, we have a streamlined way of defining these
features in `features.py` and that doesn't impact the ability for a
configuration file to stay minimal.
The original motivation for this change was that I am about to propose
a change that would touch essentially all XFAIL annotations for back-deployment
in the test suite, and this greatly reduces the number of lines changed
by that upcoming change, in addition to making the test suite generally
better.
Differential Revision: https://reviews.llvm.org/D146359
