According to https://developer.apple.com/support/xcode/, quite a few of
our availability macros don't do anything anymore, so we might as well
remove them to clean up the code a bit.
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
A few tests were also straightforward to translate to SFINAE tests
instead, so in a few cases I did that and removed the .fail.cpp test
entirely.
Differential Revision: https://reviews.llvm.org/D153149
This patch makes are code less dependant on transitive includes.
This was part of D145800. This patch will be abandoned, but these
changes are still useful. I manually verified declarations of the new
includes are used in these files.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D148645
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
This has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)size_t)|\1std::\2|' \{} \;
And manually removed some false positives in std/depr/depr.c.headers.
The `std` module doesn't export `::size_t`, this is a preparation for that module.
Reviewed By: ldionne, #libc, EricWF, philnik
Differential Revision: https://reviews.llvm.org/D146088
While testing a test failure of C++17 with Clang ToT it was noticed the
paper
P0602R4 variant and optional should propagate copy/move triviality
was not applied as a DR in libc++.
This was discovered while investigating the issue "caused by" D131479.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D133326
This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to be more like GCC and uses "static assertion"
when possible instead of hard coding the name. This also changes some
instances of 'static_assert' to instead be based on the token in the
source code.
Differential Revision: https://reviews.llvm.org/D129048
Looks like we again are going to have problems with libcxx tests that
are overly specific in their dependency on clang's diagnostics.
This reverts commit 6542cb55a3eb115b1c3592514590a19987ffc498.
This patch is basically the rewording of the static assert statement's
output(error) on screen after failing. Failing a _Static_assert in C
should not report that static_assert failed. It’d probably be better to
reword the diagnostic to be more like GCC and say “static assertion”
failed in both C and C++.
consider a c file having code
_Static_assert(0, "oh no!");
In clang the output is like:
<source>:1:1: error: static_assert failed: oh no!
_Static_assert(0, "oh no!");
^ ~
1 error generated.
Compiler returned: 1
Thus here the "static_assert" is not much good, it will be better to
reword it to the "static assertion failed" to more generic. as the gcc
prints as:
<source>:1:1: error: static assertion failed: "oh no!"
1 | _Static_assert(0, "oh no!");
| ^~~~~~~~~~~~~~
Compiler returned: 1
The above can also be seen here. This patch is about rewording
the static_assert to static assertion.
Differential Revision: https://reviews.llvm.org/D129048
Display 'static_assert failed: message' instead of
'static_assert failed "message"' to be consistent
with other implementations and be slightly more
readable.
Reviewed By: #libc, aaron.ballman, philnik, Mordante
Differential Revision: https://reviews.llvm.org/D128844
This mostly copys the `<experimental/functional>` stuff and updates the code to current libc++ style.
Reviewed By: ldionne, #libc
Spies: nlopes, adamdebreceni, arichardson, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D121074
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
This should work now that we are using a matching libunwind.dylib when
we run the tests in back-deployment scenarios. The only restriction we
have now is to run on macOS x86_64, since that's what the old dylibs
were compiled for. This should allow us to move to newer AppleClangs
in the CI.
As a fly-by, fix missing availability annotations on optional's
monadic operations.
Differential Revision: https://reviews.llvm.org/D119840
... from testing with MSVC's STL. Mostly truncation warnings and variables that are only used in `LIBCPP_ASSERT`.
Differential Revision: https://reviews.llvm.org/D116878
Add deduction guides to `valarray` and `scoped_allocator_adaptor`. This largely
finishes implementation of the paper:
* deduction guides for other classes mentioned in the paper were
implemented previously (see the list below);
* deduction guides for several classes contained in the proposal
(`reference_wrapper`, `lock_guard`, `scoped_lock`, `unique_lock`,
`shared_lock`) were removed by [LWG2981](https://wg21.link/LWG2981).
Also add deduction guides to the synopsis for the few classes (e.g. `pair`)
where they were missing.
The only part of the paper that isn't fully implemented after this patch is
making sure certain deduction guides don't participate in overload resolution
when given incorrect template parameters.
List of significant commits implementing the other parts of P0433 (omitting some
minor fixes):
* [pair](af65856eec)
* [basic_string](6d9f750dec)
* [array](0ca8c0895c)
* [deque](dbb6f8a817)
* [forward_list](e076700b77)
* [list](4a227e582b)
* [vector](df8f754792)
* [queue/stack/priority_queue](5b8b8b5dce)
* [basic_regex](edd5e29cfe)
* [optional](f35b4bc395)
* [map/multimap](edfe8525de)
* [set/multiset](e20865c387)
* [unordered_set/unordered_multiset](296a80102a)
* [unordered_map/unordered_multimap](dfcd4384cb)
* [function](e1eabcdfad)
* [tuple](1308011e1b)
* [shared_ptr/weak_ptr](83564056d4)
Additional notes:
* It was revision 2 of the paper that was voted into the Standard.
P0433R3 is a separate paper that is not part of the Standard.
* The paper also mandates removing several `make_*_searcher` functions
(e.g. `make_boyer_moore_searcher`) which are currently not implemented
(except in `experimental/`).
* The `__cpp_lib_deduction_guides` feature test macro from the paper was
accidentally omitted from the Standard.
Differential Revision: https://reviews.llvm.org/D112510
Replace `TEST_NOEXCEPT_FALSE` directly with `noexcept(false)` in
optional hash test which is only run in C++17 or later.
`TEST_NOEXCEPT_FALSE` is only useful in C++03 context where `noexcept`
isn't supported by clang. `TEST_NOEXCEPT_FALSE` now only has one remaining use
in `hash_unique_ptr.pass.cpp`.
All supported compilers have supported deduction guides in C++17 for a
while, so this isn't necessary anymore.
Differential Revision: https://reviews.llvm.org/D108213
Since we officially don't support several older compilers now, we can
drop a lot of the markup in the test suite. This helps keep the test
suite simple and makes sure that UNSUPPORTED annotations don't rot.
This is the first patch of a series that will remove annotations for
compilers that are now unsupported.
Differential Revision: https://reviews.llvm.org/D107787
std::exchange is only constexpr in C++20 and later. We were using it
in a constructor marked unconditionally constexpr, which caused issues
when building with -std=c++17.
The weird part is that the issue only showed up when building on the
arm64 macs, but that must be caused by the specific version of Clang
used on those. Since the code is clearly wrong and the fix is obvious,
I'm not going to investigate this further.
Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the triple.
Differential Revision: https://reviews.llvm.org/D104747
Makes the following operations constexpr:
* `std::swap(optional, optional)`
* `optional(optional<U> const&)`
* `optional(optional<U>&&)`
* `~optional()`
* `operator=(nullopt_t)`
* `operator=(U&&)`
* `operator=(optional<U> const&)`
* `operator=(optional<U>&&)`
* `emplace(Args&&...)`
* `emplace(initializer_list<U>, Args&&...)`
* `swap(optional&)`
* `reset()`
P2231 has been accepted by plenary, with the committee recommending
implementers retroactively apply to C++20. It's necessary for us to
implement _`semiregular-box`_ and _`non-propagating-cache`_, both of
which are required for ranges (otherwise we'll need to reimplement
`std::optional` with these members `constexpr`ified).
Differential Revision: https://reviews.llvm.org/D102119
This fixes a long standing issue where the triple is not always set
consistently in all configurations. This change also moves the
back-deployment Lit features to using the proper target triple
instead of using something ad-hoc.
This will be necessary for using from scratch Lit configuration files
in both normal testing and back-deployment testing.
Differential Revision: https://reviews.llvm.org/D102012
This reverts a224bf8ec423b42eea251407e7a6cc8398a5edf4 and fixes the
underlying issue.
The underlying issue is simply that MSVC headers contains a define
like "#define __in", where __in is one macro in the MSVC Source
Code Annotation Language, defined in sal.h
Just use a different variable name than "__in"
__indirectly_readable_impl, and add "__in" to nasty_macros.h just
like the existing __out. (Also adding a couple more potentially
conflicting ones.)
Differential Revision: https://reviews.llvm.org/D101613
Implements parts of:
* P0896R4 The One Ranges Proposal`
Depends on D100073.
Reviewed By: ldionne, zoecarver, #libc
Differential Revision: https://reviews.llvm.org/D100080
That was originally committed in 04733181b513 and then reverted in
a9f11cc0d965 because it broke several people.
The problem was a missing include of __iterator/concepts.h, which has now
been fixed.
Differential Revision: https://reviews.llvm.org/D100073
Implements parts of:
* P0896R4 The One Ranges Proposal`
Depends on D99873.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D100073
This undefined behavior was found by applying Lénárd Szolnoki's proposal
to disable implicit conversion of default_delete<D> to default_delete<B>.
The offending part of the test is circa line 243.
The wording that makes it undefined behavior is http://eel.is/c++draft/expr.delete#3 .
Differential Revision: https://reviews.llvm.org/D90536
- Several -Wshadow warnings
- Several places where we did not initialize our base class explicitly
- Unused variable warnings
- Some tautological comparisons
- Some places where we'd pass null arguments to functions expecting
non-null (in unevaluated contexts)
- Add a few pragmas to turn off spurious warnings
- Fix warnings about declarations that don't declare anything
- Properly disable deprecation warnings in ext/ tests (the pragmas we
were using didn't work on GCC)
- Disable include_as_c.sh.cpp because GCC complains about C++ flags
when compiling as C. I couldn't find a way to fix this one properly,
so I'm disabling the test. This isn't great, but at least we'll be
able to enable warnings in the whole test suite with GCC.
Also, some tests had multiple death tests in them, so split them into
separate tests instead. The second death test would obviously never
get run, because the first one would kill the program before.
Some time ago, I introduced shortcut features like dylib-has-no-shared_mutex
to encode whether the deployment target supported shared_mutex (say). This
made the test suite annotations cleaner.
However, the problem with building Lit features on top of other Lit
features is that it's easier for them to become stale, especially when
they are generated programmatically. Furthermore, it makes the bar for
defining configurations from scratch higher, since more features have
to be defined. Instead, I think it's better to put the XFAILs in the
tests directly, which allows cleaning them up with a simple grep.
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
