So we can also match aarch64 triples which have four components instead of three when disabling the test, which the case on some buildbots.
Follow on to #89305
`libcxx std::basic_ios` uses `WEOF` to indicate the `fill` value is
uninitialized. On some platforms (e.g AIX and zOS in 64-bit mode)
`wchar_t` is 4 bytes `unsigned` and `wint_t` is also 4 bytes which means
`WEOF` cannot be distinguished from `WCHAR_MAX` by
`std::char_traits<wchar_t>::eq_int_type()`, meaning this valid character
value cannot be stored on affected platforms (as the implementation
triggers reinitialization to `widen(’ ’)`).
This patch introduces a new helper class `_FillHelper` uses a boolean
variable to indicate whether the fill character has been initialized,
which is used by default in libcxx ABI version 2. The patch does not
affect ABI version 1 except for targets AIX in 32- and 64-bit and z/OS
in 64-bit (so that the layout of the implementation is compatible with
the current IBM system provided libc++)
This is a continuation of Phabricator patch
[D124555](https://reviews.llvm.org/D124555). This patch uses a modified
version of the [approach](https://reviews.llvm.org/D124555#3566746)
suggested by @ldionne .
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Co-authored-by: David Tenty <daltenty.dev@gmail.com>
This patch removes many annotations that are not relevant anymore since
we don't support or test back-deploying to macOS < 10.13. It also cleans
up raw usage of target triples to identify versions of dylibs shipped on
prior versions of macOS, and uses the target-agnostic Lit features
instead. Finally, it reorders both the Lit backdeployment features and
the corresponding availability macros in the library in a way that makes
more sense, and reformulates the Lit backdeployment features in terms of
when a version of LLVM was introduced instead of encoding the system
versions on which it hasn't been introduced yet. Although one can be
derived from the other, encoding the negative form is extremely
error-prone.
Fixes#80901
We were not making any distinction between e.g. the "Apple-flavored"
libc++ built from trunk and the system-provided standard library on
Apple platforms. For example, any test that would be XFAILed on a
back-deployment target would unexpectedly pass when run on that
deployment target against the tip of trunk Apple-flavored libc++. In
reality, that test would be expected to pass because we're running
against the latest libc++, even if it is Apple-flavored.
To solve this issue, we introduce a new feature that describes whether
the Standard Library in use is the one provided by the system by
default, and that notion is different from the underlying standard
library flavor. We also refactor the existing Lit features to make a
distinction between availability markup and the library we're running
against at runtime, which otherwise limit the flexibility of what we can
express in the test suite. Finally, we refactor some of the
back-deployment versions that were incorrect (such as thinking that LLVM
10 was introduced in macOS 11, when in reality macOS 11 was synced with
LLVM 11).
Fixes#82107
This fixes two issues.
The return value
----------------
Based on the wording
[istream.unformatted]/37
Effects: Behaves as an unformatted input function (as described above),
except that it does not count the number of characters extracted and
does not affect the value returned by subsequent calls to gcount().
After constructing a sentry object, if rdbuf() is a null pointer,
returns -1.
[istream.unformatted]/1
... It then creates an object of class sentry with the default argument
noskipws (second) argument true. If the sentry object returns true, when
converted to a value of type bool, the function endeavors to obtain the
requested input. ...
It could be argued the current behaviour is correct, however
constructing a istream rdbuf() == nullptr creates a sentry that returns
false; its state is always bad in this case.
As mentioned in the bug report, after this change the 3 major
implementations behave the same.
The setting of the state
------------------------
When pubsync returned -1 it updated the local __state variable and
returned. This early return caused the state up the istream not to be
updated to the new state.
Fixes: https://github.com/llvm/llvm-project/issues/51497
Fixes: https://github.com/llvm/llvm-project/issues/51499
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
As suggested in #73262 this enable the stream printing on Apple
backdeployment targets. This omits the check whether the file is a
terminal. This is not entirely conforming, but the differences should be
minor and are typically not observable.
Fixes https://github.com/llvm/llvm-project/issues/75225
The overloads of `println` are specified in terms of `format`. The
function `format` is specified to work with ranges.
The implementations for `println` do not include `<format>`, but
libc++'s granularized header. This means the following example does not
work
#include <vector>
#include <print>
int main() {
std::vector<int> v{1, 2, 3};
std::println("{}", v);
}
(The other print functions also require this to work, they are specified
in terms of other format functions.)
Fixes: https://github.com/llvm/llvm-project/issues/71925
Finishes implementation of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be synchronized
with the underlying stream?
Differential Revision: https://reviews.llvm.org/D156609
This change requires quite a number of changes in the tests; this is not
code I expect people to use in the wild. So I don't expect breakage for
users.
Implements:
- P2905R2 Runtime format strings, as a Defect Report
Found while running libc++'s test suite with MSVC's STL.
MSVC has a level 1 "warning C5101: use of preprocessor directive in
function-like macro argument list is undefined behavior". I don't know
why Clang doesn't complain about this.
There are some formatting tests which densely interleave preprocessor
directives within function-like macros, and they would need invasive
changes. For now, I'm just skipping those tests.
However, a few tests were only slightly affected, and I was able to add
a new test macro `TEST_IF_AIX` to make them portable.
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
`print` functions require `FILE` and `stdout` to be available and cause
compilation errors on platforms that don't support the file system.
Differential Revision: https://reviews.llvm.org/D156585
Implements parts of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be
synchronized with the underlying stream?
Depends on D150044
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D155262
Next to sanitizer-aarch64-linux-bootstrap-msan it appears asan and
hwasan are broken on aarch64. To unbreak the CI disable these two
sanitizer checks too.
The breakage was introduced by D150044.
These tests break with msan on the sanitizer-aarch64-linux-bootstrap-msan
builder. Note the x86_64 builder is not affected. To unbreak the CI
temporary disable the tests completely with msan.
The breakage was introduced by D150044.
Drive-by fix to make sure the __retarget_buffer works correctly whan
using a hint of 1. This was discovered in one of the new tests.
Drive-by fixes __retarget_buffer when initialized with size 1.
Implements parts of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be
synchronized with the underlying stream?
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D150044
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 is an ongoing series of commits that are reformatting our
Python code.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: #libc, kwk, Mordante
Differential Revision: https://reviews.llvm.org/D150763
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Note since we use clang-tidy 16 a small work-around is needed. Clang
knows -std=c++23 but clang-tidy not so for now force the lit compiler
flag to use -std=c++2b instead of -std=c++23.
Reviewed By: #libc, philnik, jloser, ldionne
Differential Revision: https://reviews.llvm.org/D150795
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
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
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 has been done using the following command
find libcxx/test -type f -exec perl -pi -e 's|^([^/]+?)((?<!::)(?<!::u)u?int(_[a-z]+)?[0-9]{1,2}_t)|\1std::\2|' \{} \;
And manually removed some false positives in std/depr/depr.c.headers.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145880
The module std does not provide c-types in the global namespace. This
means all these types need to be fully qualified. This is a first step
to convert them by using sed.
Since this is an automated conversion other types like uint64_t are kept
as is.
Note that tests in the directory libcxx/test/std/depr/depr.c.headers
should not be converted automatically. This requires manual attention,
there some test require testing uint32_t in the global namespace. These
test should fail when using the std module, and pass when using the
std.compat module.
A similar issue occurs with atomic, atomic_uint32_t is specified as
using atomic_uint32_t = atomic<uint32_t>; // freestanding
So here too we need to keep the name in the global namespace in the
tests.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D145520
The `ostream` `nullptr` inserter implemented in 3c125fe is missing a C++ version
guard. Normally, `libc++` takes the stance of backporting LWG issues to older
standards modes as was done in 3c125fe. However, backporting to older standards
modes breaks existing code in popular libraries such as `Boost.Test` and
`Google Test` who define their own overload for `nullptr_t`.
Instead, only apply this `operator<<` overload in C++17 or later.
Fixes https://github.com/llvm/llvm-project/issues/55861.
Differential Revision: https://reviews.llvm.org/D127033
Since those features are general properties of the environment, it makes
sense to use them from libc++abi too, and so the name libcpp-has-no-xxx
doesn't make sense.
Differential Revision: https://reviews.llvm.org/D126482
The pointer.volatile.pass.cpp test was already marked as XFAIL for
mingw-dll (for reasons explained in the comment above it).
The same issue also appears in clang-cl-dll when built with newer
CMake versions. (It didn't appear with older versions of CMake, as
CMake built the library with the clang-cl flag `-std:c++latest` when
we've requested C++ 20 - which practically built it in c++2b mode with
current clang versions. With current versions of CMake, it passes
`-std:c++20` instead.)
As it succeeds/fails dependent on factors we don't
directly control, mark it as UNSUPPORTED instead of XFAIL.
Differential Revision: https://reviews.llvm.org/D122718
Move `__quoted_output_proxy` into the one file that uses it.
A `const char*` has no associated traits class, so `std::quoted("literal")`
should be printable into any basic_ostream regardless of traits.
Use hidden-friend `operator<<` and `operator>>`, since we're permitted to.
(The exact signature is unspecified because the class itself is unspecified.)
We shouldn't support `std::quoted("literal")` in C++03 or C++11 mode.
(We do need `std::__quoted(s)` and `std::__quoted(cs)` in C++11 mode,
because they're used by `std::__fs::filesystem::path`.)
Differential Revision: https://reviews.llvm.org/D120135
In the en_US locale on Windows, negative currency amounts is formatted
as "($0.01)" instead of "-$0.01".
Adjust the test references accordingly, making these tests pass.
Differential Revision: https://reviews.llvm.org/D120798
Mention support for MinGW in the docs. Rename the existing windows
CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much
"Windows", just different toolchain environments.
Add an XFAIL for a recently added test that fails in the MinGW DLL
configuration (with an explanation of what's causing the failure).
Differential Revision: https://reviews.llvm.org/D112215
Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.
Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.
Differential Revision: https://reviews.llvm.org/D111265
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
With the STL containers, I didn't enable move operations in C++03 mode
because that would change the overload resolution for things that today
are copy operations. With iostreams, though, the copy operations aren't
present at all, and so I see no problem with enabling move operations
even in (Clang's greatly extended) C++03 mode.
Clang's C++03 mode does not support delegating constructors.
Differential Revision: https://reviews.llvm.org/D104310
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 makes no attempt yet to look into the why/what for each of them,
but makes the CI configuration useful for tracking further regressions.
After looking into each case, they can either be fixed, or converted
into UNSUPPORTED: windows or XFAIL: windows, once the cause is known
and explained.
A number of the filesystem cases can be fixed by patches that are
currently in review.
Differential Revision: https://reviews.llvm.org/D99095
