I've structured this into a series of commits for even easier reviewing,
if that helps. I could easily split this up into separate PRs if
desired, but as this is low-risk with simple edits, I thought one PR
would be easiest.
* Drop unnecessary semicolons after function definitions.
* Cleanup comment typos.
* Cleanup `static_assert` typos.
* Cleanup test code typos.
+ There should be no functional changes, assuming I've changed all
occurrences.
* ~~Fix massive test code typos.~~
+ This was a real problem, but needed more surgery. I reverted those
changes here, and @philnik777 is fixing this properly with #73444.
* clang-formatting as requested by the CI.
Found while running libc++'s test suite with MSVC's STL.
This is structured into a series of commits for easier reviewing; I
could also split this into smaller PRs if desired.
* Add void-casts for `invoke_r` calls to fix MSVC STL `[[nodiscard]]`
warnings.
+ Our rationale is that if someone is calling `invoke_r<NonVoidType>`,
it sure looks like they care about the return value.
* Add `[[maybe_unused]]` to silence `-Wunused-parameter` warnings.
+ This happens because the parameters are used within `LIBCPP_ASSERT`,
which vanishes for MSVC's STL. This also motivates the following
changes.
* Add `[[maybe_unused]]` to fix `-Wunused-variable` warnings.
* Always void-cast `debug_comparisons` to fix `-Wunused-variable`
warnings.
+ As this was already unused with a void-cast in one
`_LIBCPP_HARDENING_MODE` branch, I'm simply lifting it next to the
variable definition.
* Add `[[maybe_unused]]` to fix `-Wunused-local-typedef` warnings.
This makes the conditionals quite a bit simpler to understand, since it
avoids double negatives and makes sure we have <__availability>
included. For vendors which use availability macros, it also enforces
that they check when specific features are introduced and define the
macro for their platform appropriately.
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.
Mark tests as necessary to accommodate Android L (5.0 / API 21) and up.
Add three Android lit features:
- android
- android-device-api=(21,22,23,...)
- LIBCXX-ANDROID-FIXME (for failures that need follow-up work)
Enable an AIX workaround in filesystem_test_helper.h for the broken
chmod on older Android devices.
Mark failing test with XFAIL or UNSUPPORTED:
- Mark modules tests as UNSUPPORTED, matching other configurations.
- Mark a gdb test as UNSUPPORTED.
- XFAIL tests for old devices that lack an API (fmemopen).
- XFAIL various FS tests (because SELinux blocks FIFO and hard linking,
because fchmodat is broken on old devices).
- XFAIL various locale tests (because Bionic has limited locale
support). (Also XFAIL an re.traits test.)
- XFAIL some print.fun tests because the error exception has no system
error string.
- Mark std::{cin,wcin} tests UNSUPPORTED because they hang with
adb_run.py on old devices.
- Mark a few tests UNSUPPORTED because they allocate too much memory.
- notify_one.pass.cpp is flaky on Android.
- XFAIL libc++abi demangler test because of Android's special long
double on x86[-64].
N.B. The `__ANDROID_API__` macro specifies a minimum required API level
at build-time, whereas the android-device-api lit feature is the
detected API level of the device at run-time. The android-device-api
value will be >= `__ANDROID_API__`.
This commit was split out from https://reviews.llvm.org/D139147.
Fixes: https://github.com/llvm/llvm-project/issues/69270
This patch introduces the support::make_test_jthread utility which is
basically the same as support::make_test_thread but for std::jthread. It
allows vendors to maintain a downstream way to create threads for use
within the test suite, which is especially useful for embedded
platforms.
This patch removes the non compliant constructor of std::future_error
and adds the standards compliant constructor in C++17 instead.
Note that we can't support the constructor as an extension in all
standard modes because it uses delegating constructors, which require
C++11. We could in theory support the constructor as an extension in
C++11 and C++14 only, however I believe it is acceptable not to do that
since I expect the breakage from this patch will be minimal.
If it turns out that more code than we expect is broken by this, we can
reconsider that decision.
This was found during D99515.
Differential Revision: https://reviews.llvm.org/D99567
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Since LLVM 17 has been branched and is on the verge of being released,
we can drop the CI job that tests against Clang 15. I think the number
of cherry-picks to `release/17.x` will be a lot smaller now, so keeping
a Clang 15 job around for that purpose seems unnecessary.
As a fly-by, this patch also removes some Clang 15 workarounds and test
suite annotations as we usually do. It also removes some slightly older
gcc test suite annotations that were missed.
AppleClang 15 was released on September 18th and is now stable. Per our
policy, we're bumping the supported AppleClang compiler to the latest
release. This allows cleaning up the test suite, but most importantly
unblocking various other patches that are blocked on bumping the
compiler requirements.
When a handle to an error_category singleton object is used during the
termination phase of a program, the destruction of the error_category
object may have occurred prior to execution of the current destructor
or function registered with atexit, because the singleton object may
have been constructed after the corresponding initialization or call
to atexit. For example, the updated tests from this patch will fail if
using a libc++ built using a compiler that updates the vtable of the
object on destruction.
This patch attempts to avoid the issue by causing the destructor to not
be called in the style of ResourceInitHelper in src/experimental/memory_resource.cpp.
This approach might not work if object lifetime is strictly enforced.
Differential Revision: https://reviews.llvm.org/D65667
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Adding assertions will aid users that have bugs or logic mistakes in
their code to receive error messages when debugging.
Differential Revision: https://reviews.llvm.org/D155399
Improves both the compile-time and run-time errors.
At compile-time it does a bit more work to get more specific errors.
This could be done at run-time too, but that has a performance penalty.
Since it's expected most use-cases use format* instead of vformat* the
compile-time errors are more common.
For example when using
std::format_to("{:-c}", 42);
Before compile output would contain
std::__throw_format_error("The format-spec should consume the input or end with a '}'");
Now it contains
std::__throw_format_error("The format specifier does not allow the sign option");
Given a better indication the sign option is not allowed. Note the
output is still not user-friendly; C++ doesn't have good facilities to
generate nice messages from the library.
In general all messages have been reviewed and improved, using a more
consistent style and using less terms used in the standard. For example
format-spec -> format specifier
arg-id -> argument index
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D152624
The output of
template<class charT, class traits>
basic_ostream<charT, traits>&
operator<<(basic_ostream<charT, traits>& out, thread::id id);
is affected by the state of out. The wording states
[thread.thread.id]/2
The text representation for the character type charT of an object of
type thread::id is an unspecified sequence of charT such that, for two
objects of type thread::id x and y, if x == y is true, the thread::id
objects have the same text representation, and if x != y is true, the
thread::id objects have distinct text representations.
[thread.thread.id]/9
template<class charT, class traits>
basic_ostream<charT, traits>&
operator<< (basic_ostream<charT, traits>& out, thread::id id);
Effects: Inserts the text representation for charT of id into out.
This wording changed in C++23 due to adding a formatter specialization for
thread::id. However the requirement was the same in older versions of C++.
This issue is that thread::id is an integral or pointer and affected by the
formatting manipulators for them. Thus the text representation can differ if
x == y which violates the requirements.
The fix has to hard-code some formatting style for the text
representation. It uses the Standard specified default values
Table 124: basic_ios::init() effects [tab:basic.ios.cons] flags()
flags() skipws | dec
Fixes PR: https://llvm.org/PR62073
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D153336
Currently, there are no tests to confirm without a doubt the constructor of latch is really constexpr and explicit.
I think this would be an addition that it would not harm to have. In another revision, I was asked to add tests for an almost identical case which made me consider adding this test for the latch class too.
Reviewed By: #libc, philnik
Spies: philnik, libcxx-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D154957
If I read the standard correctly, the public constructor of "barrier" should be marked as "constexpr explicit".
I see some of the internal classes used by the barrier header are correctly marked but I think, if I'm not mistaken, the standard would like the public class to have the correct definition as well.
Because the implementation that llvm uses by default is not constexpr friendly at this time, this revision will focus on only marking it as explicit.
Reviewed By: #libc, philnik, Mordante
Spies: philnik, Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D154590
This makes <__threading_support> closer to handling only the bridge
between the system's implementation of threading and the rest of libc++.
Differential Revision: https://reviews.llvm.org/D154464
There are discussions about different ways of implementing `stop_token` to make it more performant
mark `stop_token` as experimental to allow us to change the design before it is shipped
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Differential Revision: https://reviews.llvm.org/D154700
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
Those were found while trying to enable configurations like no-threads
and no-localization with Clang modules enabled.
Differential Revision: https://reviews.llvm.org/D153977
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
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
The code has been quite ready for a while now and there are no more ABI
breaking papers. So this is a good time to mark the feature as stable.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D150802
Like done D149543 this validates the other formatter specializations.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D150041
This is based on the last open review comment in D144331 and is applied
to all occurrences.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D147885
This file was added before we started granularizing the headers, but is essentially just a granularized header. This moves the header to the correct place.
Reviewed By: #libc, EricWF
Spies: libcxx-commits, arichardson, mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D146395
Since stacktrace header is WIP and it's not sure that will be done
before LLVM17 update the documentation. When the header is implemented
implementing the formatter is trivial, so that can be done quickly
afterwards.
Implements parts of:
- P2693R1 Formatting thread::id and stacktrace
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D144331
The use_system_cxx_lib Lit feature was only used for back-deployment
testing. However, one immense hole in that setup was that we didn't
have a proper way to test Apple's own libc++ outside of back-deployment,
which was embodied by the fact that we needed to define _LIBCPP_DISABLE_AVAILABILITY
when testing (see change in libcxx/utils/libcxx/test/params.py).
This led to the apple-system testing configuration not checking for
availability markup, which is obviously quite bad since the library
we ship actually has availability markup.
Using stdlib=<VENDOR>-libc++ instead to encode back-deployment restrictions
on tests is simpler and it makes it possible to naturally support tests
such as availability markup checking even in the tip-of-trunk Apple-libc++
configuration.
Differential Revision: https://reviews.llvm.org/D146366
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 also updates the moved code to the current style. (i.e. `_VSTD` -> `std`, `_LIBCPP_INLINE_VISIBILITY` -> `_LIBCPP_HIDE_FROM_ABI`, clang-format).
Reviewed By: Mordante, #libc, EricWF
Spies: arichardson, libcxx-commits, mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D146228
This has been done using the following commands
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)ptrdiff_t)|\1std::\2|' \{} \;
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)max_align_t)|\1std::\2|' \{} \;
The std module doesn't export declarations in the global namespaace.,
This is a preparation for that module.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D146550
As explained in the release note, libc++ used to provide various
global variables as an extension in C++03 mode. Unfortunately, that
made our definition non-conforming in all standard modes. This was
never a big problem until recently, since we are trying to support
C++20 Modules in libc++, and that requires cleaning up the definition
of these variables.
This change is the first in a series of changes to achieve our end goal.
This patch removes the ability for users to rely on the (incorrect)
definition of those global variables inside the shared library. The
plan is to then remove those definitions from the shared library
(which is an ABI break but I don't think it will have impact), and
finally to make our definition of those variables conforming in all
standard modes.
Differential Revision: https://reviews.llvm.org/D145422
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
While investigating the flaky tests on the mac backdeployment targets
it seems the tests are different than suggested in the LWG issue.
That tests "does work", grabs the mutex, marks the task as done, and
finally calls the notifier.
Our test emulated "does work" after the notification, effectively
sleeping with a lock held. This has been fixed.
A second improvement is that the test fails when, due to OS
scheduling, the condition variable is not used in the main thread.
During discussing the approach of the patch with @ldionne, he
noticed the real reason why the test is flaky; the Apple
backdeployment targets use a dylib, which does not contain the
fix. So the test can't be tested on that platform; it only
proves the LWG issue was correct and the Standard contained
a bug.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D143816
Releasing the mutex before the call to notify_all is an optimization.
This optimization cannot be used here. The thread waiting on the
condition might destroy the associated resources — mutex + condition
variable — and the notifier thread will access an destroyed variable
— the condition variable. In fact, notify_all_at_thread_exit is meant
exactly to join on detached threads, and the waiting thread doesn't
expect for the notifier thread to access any further shared resources,
making this scenario very likely to happen. The waiting thread might
awake spuriously on the release of the mutex lock. The reorder is
necessary to prevent this race.
Further details can be found at https://cplusplus.github.io/LWG/issue3343.
Differential Revision: https://reviews.llvm.org/D105758
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
This is a re-application of the original patch by Eric Fiselier in
fcd549a7d828 which had been reverted due to reasons lost at this point.
I also added the macro to a few more types. Reviving this patch was
prompted by the discussion on https://llvm.org/D133425.
Differential Revision: https://reviews.llvm.org/D133535
Increase the timeout tolerance if TEST_IS_EXECUTED_IN_A_SLOW_ENVIRONMENT
is set, similarly to how it's done in a couple other tests.
Use `std::this_thread::yield();` instead of busylooping. When multiple
threads are busylooping, it's plausible that not all threads even get
started running before the timeout runs out.
This makes the threading tests succeed if run in Windows runners on
Github Actions.
Differential Revision: https://reviews.llvm.org/D131483
This makes its role clearer. It's plausible that one may want to manually
define TEST_IS_EXECUTED_IN_A_SLOW_ENVIRONMENT when running the tests in
some environments - in particular, it seems to be necessary to use the
higher tolerance timeouts if running the tests on Windows runners
on Github Actions.
Also add the descriptive comment in one file where it was missing.
Differential Revision: https://reviews.llvm.org/D131484
