[NFC][libc++][test] Removes C++98 support. (#92930)

Libc++ has no separate C++98 support, it uses C++03 instead. This
removes some obsolete c++98 markers in the test.

Thanks to @StephanTLavavej

[NFC][libc++][test] Removes C++98 support. (#92930)

Libc++ has no separate C++98 support, it uses C++03 instead. This
removes some obsolete c++98 markers in the test.

Thanks to @StephanTLavavej for spotting this.

show more ...

[libc++] Remove availability annotations which can never be triggered (#69226)

According to https://developer.apple.com/support/xcode/, quite a few of
our availability macros don't do anything anym

[libc++] Remove availability annotations which can never be triggered (#69226)

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.

show more ...

[libc++] Use named Lit features to flag back-deployment XFAILs

Instead of writing something like `XFAIL: use_system_cxx_lib && target=...`
to XFAIL back-deployment tests, introduce named Lit feature

[libc++] Use named Lit features to flag back-deployment XFAILs

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

show more ...

[libc++] Suppress -Wctad-maybe-unsupported on types w/o deduction guides

There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides

[libc++] Suppress -Wctad-maybe-unsupported on types w/o deduction guides

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

show more ...