The default triple of Amazon Linux on AArch64 is aarch64-amazon-linux,
see issue highlighded by PR #109263, somewhat serious linker issues are
encountered if any other triple is being used.
Unfortunately, this makes XFAIL lines like
`XFAIL: target=aarch64{{.*}}-linux-gnu` ineffective, making it
impossible to complete all of the check-cxx on Amazon Linux without
failing.
The effect of this commit is too broad and may affect also those
variants of Linux systems on which the affected test cases are known to
pass.
An alternative version of this commit will be prepared afresh.
This reverts commit c93dc581d979eb20ded470d2c16e51b3e775f6e7.
The default triple of Amazon Linux on AArch64 is aarch64-amazon-linux,
see issue highlighded by PR #109263, somewhat serious linker issues are
encountered if any other triple is being used.
Unfortunately, this makes XFAIL lines like:
`XFAIL: target=aarch64{{.*}}-linux-gnu` ineffective,
making it impossible to complete all of the check-cxx without failures.
Asan reports it after #124103.
It's know case of false positive for Asan.
https://github.com/google/sanitizers/wiki/AddressSanitizerInitializationOrderFiasco#false-positives
It's can be avoided with `constexpr` constructors.
In general order global constructors in different
modules is undefined. If global constructor uses
external global, they can be not constructed yet.
However, implementation may contain workaround for
that, or the state of non-constructed global can
be still valid.
Asan will still falsely report such cases, as it
has no machinery to detect correctness of such
cases.
We need to fix/workaround the issue in libc++, as
it will affect many libc++ with Asan users.
This adds a test for an issue reported downstream at
https://github.com/mstorsjo/llvm-mingw/issues/462; this is known to fail
on Windows right now, where the fseek/ftell calls end up truncated to 32
bits.
The test for this, unfortunately, requires temporarily creating a 4 GB
file.
The `std::error_code`/`std::error_category` functionality is designed to
support multiple error domains. On Unix, both system calls and libc
functions return the same error codes, and thus, libc++ today treats
`generic_category()` and `system_category()` as being equivalent.
However, on Windows, libc functions return `errno.h` error codes in the
`errno` global, but system calls return the very different `winerror.h`
error codes via `GetLastError()`.
As such, there is a need to map the winerror.h error codes into generic
errno codes. In libc++, however, the system_error facility does not
implement this mapping; instead the mapping is hidden inside libc++,
used directly by the std::filesystem implementation.
That has a few problems:
1. For std::filesystem APIs, the concrete windows error number is lost,
before users can see it. The intent of the distinction between
std::error_code and std::error_condition is that the error_code return
has the original (potentially more detailed) error code.
2. User-written code which calls Windows system APIs requires this same
mapping, so it also can also return error_code objects that other
(cross-platform) code can understand.
After this commit, an `error_code` with `generic_category()` is used to
report an error from `errno`, and, on Windows only, an `error_code` with
`system_category()` is used to report an error from `GetLastError()`. On
Unix, system_category remains identity-mapped to generic_category, but
is never used by libc++ itself.
The windows error code mapping is moved into system_error, so that
conversion of an `error_code` to `error_condition` correctly translates
the `system_category()` code into a `generic_category()` code, when
appropriate.
This allows code like:
`error_code(GetLastError(), system_category()) == errc::invalid_argument`
to work as expected -- as it does with MSVC STL.
(Continued from old phabricator review [D151493](https://reviews.llvm.org/D151493))
This optimizes `std::filesystem::copy_file` to use the `copy_file_range`
syscall (Linux and FreeBSD) when available. It allows for reflinks on
filesystems such as btrfs, zfs and xfs, and server-side copy for network
filesystems such as NFS.
This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the
RFC, we initially proposed selecting the right headers from the Clang
driver, however consensus seemed to steer towards handling this in the
library itself. This patch implements that direction.
At a high level, the changes basically amount to making each public
header look like this:
```
// inside <vector>
#ifdef _LIBCPP_CXX03_LANG
# include <__cxx03/vector>
#else
// normal <vector> content
#endif
```
In most cases, public headers are simple umbrella headers so there isn't
much code in the #else branch. In other cases, the #else branch contains
the actual implementation of the header.
Instead of going through the old locale entry points, define the base
localization API for BSD-like platforms (Apple and FreeBSD) from
scratch, using <xlocale.h> as a basis. This doesn't actually change how
that functionality is implemented, it only avoids going through a maze
to do so.
This clean new support is implemented in a separate __locale_dir/support
directory, which mirrors what we do for the threading support API.
Eventually, everything under __locale_dir/locale_base_api will go away.
rdar://131476632
This removes the need for macOS nodes in Buildkite. It also moves to the
proper way of testing backdeployment, which is to actually run on the
target OS itself, instead of using packaged dylibs from previous OS
versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH.
As a drive-by change, also fix a few back-deployment annotations that
were incorrect and add support for minor versions in the Lit feature
determining availability from the target triple.
The poisoned_hash_helper header was relying on an implicit forward
declaration of std::hash located in <type_traits>. When we improve the
modularization of the library, that causes issues, in addition to being
a fundamentally non-portable assumption in the test suite.
It turns out that the reason for relying on a forward declaration is to
be able to test that std::hash is *not* provided if we don't include any
header that provides it. But testing that is actually both non-portable
and not really useful.
Indeed, what harm does it make if additional headers provide std::hash
specializations? That would certainly be conforming -- the Standard
never requires an implementation to avoid providing a declaration when a
given header is included, instead it mandates what *must* be provided
for sure. In that spirit, it would be conforming for e.g. `<cstddef>` to
define the hash specializations if that was our desire. I also don't
read https://wg21.link/P0513R0 as going against that statement. Hence,
this patch just removes that test which doesn't carry its weight.
Fixes#56938
This patch adds caching of file attributes during directory iteration
on Windows. This improves the performance when working with files being
iterated on in a directory.
Various functions like hash_value, lexically_proximate and lexically_relative
would incorrectly handle backslashes in the root directory on Windows, causing
behavior that is inconsistent with the equality comparison for a path.
This adds addressof at the required places in [input.output]. Some of
the new tests failed since string used operator& internally. These have
been fixed too.
Note the new fstream tests perform output to a basic_string instead of a
double. Using a double requires num_get specialization
num_get<CharT, istreambuf_iterator<CharT,
char_traits_operator_hijacker<CharT>>
This facet is not present in the locale database so the conversion would
fail due to a missing locale facet. Using basic_string avoids using the
locale.
As a drive-by fixes several bugs in the ofstream.cons tests. These
tested ifstream instead of ofstream with an open mode.
Implements:
- LWG3130 [input.output] needs many addressof
Closes#100246.
The tests kept being based on std::string instead of std::string_view to
allow testing with older C++ dialects.
Adds tests for:
- LWG3112 system_error and filesystem_error constructors taking a string
may not be able to meet their postconditions
As mentioned in the LWG issue libc++ has already implemented the
optimization. This adds tests and documents the implementation defined
behaviour.
Drive-by fixes an initialization.
This PR is required to fix copy_file_large.pass.cpp which is failing on
z/OS in all ASCII variations. The problem is that a destination file is
opened in binary mode and auto-conversion does not happen when this lit
is compiled with -fzos-le-char-mode=ascii.
In addition opening a destination file will match a text mode of
`fopen()` of a source file.
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
3 error_code related cleanups/corrections in the std::filesystem
operations functions.
1. In `__copy`, the `ec->clear()` is unnecessary as `ErrorHandler` at
the start of each function clears the error_code as part of its
initialization.
2. In `__copy`, in the recursive codepath we are not checking the
error_code result of `it.increment(m_ec2)` immediately after use in the
for loop condition (and we aren't checking it after the final increment
when we don't enter the loop).
3. In `__weakly_canonical`, it makes calls to `__canonical` (which
internally uses OS APIs implementing POSIX `realpath`) and we are not
checking the error code result from the `__canonical` call. Both
`weakly_canonical` and `canonical` are supposed to set the error_code
when underlying OS APIs result in an error
(https://eel.is/c++draft/fs.err.report#3.1). With this change we
propagate up the error_code from `__canonical` caused by any underlying
OS API failure up to the `__weakly_canonical`. Essentially, if
`__canonical` thinks an error code should be set, then
`__weakly_canonical` must as well. Before this change it would be
throwing an exception in the non-error_code form of the function when
`__canonical` fails, while not setting the error code in the error_code
form of the function (an inconsistency).
Added a little coverage in weakly_canonical.pass.cpp for the error_code
forms of the API that was missing. Though I am lacking utilities in
libcxx testing to add granular testing of the failure scenarios (like
forcing realpath to fail for a given path, as it could if you had
something like a flaky remote filesystem).
* Guard `std::__make_from_tuple_impl` tests with `#ifdef _LIBCPP_VERSION` and `LIBCPP_STATIC_ASSERT`.
* Change `_LIBCPP_CONSTEXPR_SINCE_CXX20` to `TEST_CONSTEXPR_CXX20`.
+ Other functions in `variant.swap/swap.pass.cpp` were already using the proper test macro.
* Mark `what` as `[[maybe_unused]]` when used by `TEST_LIBCPP_REQUIRE`.
+ This updates one occurrence in `libcxx/test/libcxx` for consistency.
* Windows `_putenv_s()` takes 2 arguments, not 3.
+ See MSVC documentation: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/putenv-s-wputenv-s?view=msvc-170
+ POSIX `setenv()` takes `int overwrite`, but Windows `_putenv_s()` always overwrites.
* Avoid non-Standard zero-length arrays.
+ Followup to #74183 and #79792.
* Add `operator++()` to `unsized_it`.
+ The Standard requires this due to [N4981][] [move.iter.requirements]/1 "The template parameter `Iterator` shall
either meet the *Cpp17InputIterator* requirements ([input.iterators])
or model `input_iterator` ([iterator.concept.input])."
+ MSVC's STL requires this because it has a strengthened exception
specification in `move_iterator` that inspects the underlying iterator's
increment operator.
* `uniform_int_distribution` forbids `int8_t`/`uint8_t`.
+ See [N4981][] [rand.req.genl]/1.5. MSVC's STL enforces this.
+ Note that when changing the distribution's `IntType`, we need to be
careful to preserve the original value range of `[0, max_input]`.
* fstreams are constructible from `const fs::path::value_type*` on wide systems.
+ See [ifstream.cons], [ofstream.cons], [fstream.cons].
* In `msvc_stdlib_force_include.h`, map `_HAS_CXX23` to `TEST_STD_VER` 23 instead of 99.
+ On 2023-05-23, 71400505ca
started recognizing 23 as a distinct value.
* Fix test name typo: `destory_elements.pass.cpp` => `destroy_elements.pass.cpp`
[N4981]: https://wg21.link/N4981
This patch implements LWG4023 by adding explicit assertions for the
added preconditions and also fixes a few tests that were violating these
preconditions.
On Windows you can not create symlinks without elevated privileges
unless you have Windows developer mode enabled. There's ~67 libcxx tests
that run into failures on windows if your environment is not set up
correctly (Go to windows settings and enable "developer mode").
This change:
- Adds a feature check for whether the host can create symlinks. (see
libcxx/utils/libcxx/test/features.py)
- Mark the feature as required for the 67 tests that hit failures on
windows due to this. This will allow lit to correctly mark these tests
as unsupported instead of unexpectedly failed (this is helpful since
then you know you didn't break something with your change, it's just
that it's not supported with your environment).
When calling setbuf(nullptr, 0) before performing file operations it
should set the file to unbuffered mode. Currently the code avoids
buffering internally, but the underlying stream still can buffer.
This is addressed by disabling the buffering of the underlying stream.
Fixes: https://github.com/llvm/llvm-project/issues/60509
When echo is used for piping, lit uses the system echo rather than the
builtin echo. The system echo on AIX doesn't support the `-n` option,
which causes these tests to fail. Use input redirection, so the builtin
echo can be used.
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>
remove_all_impl() opens the target path with O_NOFOLLOW, which fails if
the target is a symbolic link. On FreeBSD, rather than returning ELOOP,
openat() returns EMLINK. This is unlikely to change for compatibility
reasons, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214633 .
Thus, check for EMLINK as well.
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
This patch adds a configuration of the libc++ test suite that enables
optimizations when building the tests. It also adds a new CI
configuration to exercise this on a regular basis. This is added in the
context of [1], which requires building with optimizations in order to
hit the bug.
[1]: https://github.com/llvm/llvm-project/issues/68552
