[libcxx] Handle windows system error code mapping in std::error_code. (#93101)

The `std::error_code`/`std::error_category` functionality is designed to
support multiple error domains. On Unix, both

[libcxx] Handle windows system error code mapping in std::error_code. (#93101)

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))

show more ...

[libcxx] Fix build for glibc < 2.27 (#121893)

PR #109211 introduced a build break on systems with glibc < 2.27, since
copy_file_range was only introduced after that version. A version check
is added

[libcxx] Fix build for glibc < 2.27 (#121893)

PR #109211 introduced a build break on systems with glibc < 2.27, since
copy_file_range was only introduced after that version. A version check
is added to prevent this breakage.

show more ...

[libc++] Fix largefile handling in fs::copy_file (#121855)

Fix for issues reported in https://github.com/llvm/llvm-project/pull/109211

[libc++] Use copy_file_range for fs::copy (#109211)

This optimizes `std::filesystem::copy_file` to use the `copy_file_range`
syscall (Linux and FreeBSD) when available. It allows for reflinks on
f

[libc++] Use copy_file_range for fs::copy (#109211)

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.

show more ...

[libc++][NFC] Increase consistency for namespace closing comments

[libc++] Get the GCC build mostly clean of warnings (#96604)

The GCC build has gotten to the point where it's often hard to find the
actual error in the build log. We should look into enabling thes

[libc++] Get the GCC build mostly clean of warnings (#96604)

The GCC build has gotten to the point where it's often hard to find the
actual error in the build log. We should look into enabling these
warnings again in the future, but it looks like a lot of them are
bogous.

show more ...

[libcxx] Correct and clean-up filesystem operations error_code paths (#88341)

3 error_code related cleanups/corrections in the std::filesystem
operations functions.

1. In `__copy`, the `ec->clea

[libcxx] Correct and clean-up filesystem operations error_code paths (#88341)

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).

show more ...

[libc++] Fix UB in filesystem::__copy for non-existent destination. (#87615)

The lstat/stat/fstat functions have no guarantee whether the `struct stat`
buffer is changed or not on failure. The file

[libc++] Fix UB in filesystem::__copy for non-existent destination. (#87615)

The lstat/stat/fstat functions have no guarantee whether the `struct stat`
buffer is changed or not on failure. The filesystem::__copy function assumes
that the `struct stat` buffer is not updated on failure, which is not
necessarily correct.

It appears that for a non-existing destination `detail::posix_lstat(to,
t_st, &m_ec1)` returns a failure indicator and overwrites the `struct stat`
buffer with a garbage value, which is accidentally equal to the `f_st` from
stack internals from the previous `detail::posix_lstat(from, f_st, &m_ec1)`
call.

file_type::not_found is a known status, so checking against
`if (not status_known(t))` passes spuriously and execution continues.
Then the __copy function returns errc::function_not_supported because stats
are accidentally equivalent, which is incorrect.

Before checking for `detail::stat_equivalent`, we instead need to make sure
that the call to lstat/stat/fstat was successful.

As a result of `f_st` and `t_st` not being accessed anymore without checking
for the lstat/stat/fstat success indicator, it is not needed to zero-initialize
them.

show more ...

[libc++] Fix filesystem::remove_all() on FreeBSD (#79540)

remove_all_impl() opens the target path with O_NOFOLLOW, which fails if
the target is a symbolic link. On FreeBSD, rather than returning EL

[libc++] Fix filesystem::remove_all() on FreeBSD (#79540)

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.

show more ...

[libc++][hardening] Classify assertions related to leaks and syscalls. (#77164)

Introduce two new categories:
- `_LIBCPP_ASSERT_VALID_DEALLOCATION`;
- `_LIBCPP_ASSERT_VALID_EXTERNAL_API_CALL`.

[libc++][hardening] Categorize assertions that produce incorrect results (#77183)

Introduce a new `argument-within-domain` category that covers cases
where the given arguments make it impossible to

[libc++][hardening] Categorize assertions that produce incorrect results (#77183)

Introduce a new `argument-within-domain` category that covers cases
where the given arguments make it impossible to produce a correct result
(or create a valid object in case of constructors). While the incorrect
result doesn't create an immediate problem within the library (like e.g.
a null pointer dereference would), it always indicates a logic error in
user code and is highly likely to lead to a bug in the program once the
value is used.

show more ...

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmar

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

find libcxx/include libcxx/src -type f \
| grep -v 'module.modulemap.in' \
| grep -v 'CMakeLists.txt' \
| grep -v 'README.txt' \
| grep -v 'libcxx.imp' \
| grep -v '__config_site.in' \
| xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all

show more ...

[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.

Replace most uses of `_LIBCPP_ASSERT` with
`_LIBCPP_ASSERT_UNCATEGORIZED`.

This is done as a prerequisite to introducing hardened

[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.

Replace most uses of `_LIBCPP_ASSERT` with
`_LIBCPP_ASSERT_UNCATEGORIZED`.

This is done as a prerequisite to introducing hardened mode to libc++.
The idea is to make enabling assertions an opt-in with (somewhat)
fine-grained controls over which categories of assertions are enabled.
The vast majority of assertions are currently uncategorized; the new
macro will allow turning on `_LIBCPP_ASSERT` (the underlying mechanism
for all kinds of assertions) without enabling all the uncategorized
assertions (in the future; this patch preserves the current behavior).

Differential Revision: https://reviews.llvm.org/D153816

show more ...

[libc++][filesystem] Avoid using anonymous namespaces in support headers

This avoids using anonymous namespaces in headers and ensures that
the various helper functions get deduplicated across the T

[libc++][filesystem] Avoid using anonymous namespaces in support headers

This avoids using anonymous namespaces in headers and ensures that
the various helper functions get deduplicated across the TUs
implementing <filesystem>. Otherwise, we'd get a definition of
these helper functions in each TU where they are used, which is
entirely unnecessary.

Differential Revision: https://reviews.llvm.org/D152378

show more ...

[libc++] Split sources for <filesystem>

The operations.cpp file contained the implementation of a ton of
functionality unrelated to just the filesystem operations, and
filesystem_common.h contained

[libc++] Split sources for <filesystem>

The operations.cpp file contained the implementation of a ton of
functionality unrelated to just the filesystem operations, and
filesystem_common.h contained a lot of unrelated functionality as well.

Splitting this up into more files will make it possible in the future
to support parts of <filesystem> (e.g. path) on systems where there is
no notion of a filesystem.

Differential Revision: https://reviews.llvm.org/D152377

show more ...

[libc++] Android temp dir is /data/local/tmp, enable Windows test

[libc++] Android temp dir is /data/local/tmp, enable Windows test

On Android, std::filesystem::temp_directory_path() should fall ba

[libc++] Android temp dir is /data/local/tmp, enable Windows test

[libc++] Android temp dir is /data/local/tmp, enable Windows test

On Android, std::filesystem::temp_directory_path() should fall back to
/data/local/tmp when no environment variable is set. There is no /tmp
directory. Most apps can't access /data/local/tmp, but they do have a
"cache dir" (Context#getCacheDir()) that is usable for temporary files.
However, there is no obvious and reliable way for libc++ to query this
directory in contexts where it is available. The global fallback
/data/local/tmp is available for "adb shell", making it useful for test
suites.

On Windows, temp_directory_path falls back to the Windows directory
(e.g. "C:\Windows"), so call GetWindowsDirectoryW to do the test.

Reviewed By: ldionne, #libc, enh

Differential Revision: https://reviews.llvm.org/D137131

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 ...

[SystemZ][z/OS] define REMOVE_ALL_USE_DIRECTORY_ITERATOR (libc++)

This patch fixes the z/OS build by using the first implementation of __remove_all since we don't have access to the openat() family

[SystemZ][z/OS] define REMOVE_ALL_USE_DIRECTORY_ITERATOR (libc++)

This patch fixes the z/OS build by using the first implementation of __remove_all since we don't have access to the openat() family of POSIX functions.

Differential Revision: https://reviews.llvm.org/D132948

show more ...

Fix "the the" typo in documentation and user facing strings

There are many more instances of this pattern, but I chose to limit this change to .rst files (docs), anything in libcxx/include, and stri

Fix "the the" typo in documentation and user facing strings

There are many more instances of this pattern, but I chose to limit this change to .rst files (docs), anything in libcxx/include, and string literals. These have the highest chance of being seen by end users.

Reviewed By: #libc, Mordante, martong, ldionne

Differential Revision: https://reviews.llvm.org/D124708

show more ...

[libc++] Rename PS() macro to avoid clashing with Xtensa register name

This patch addresses a clash with the PS register from Xtensa
defined in the <specreg.h> header file, which is commonly include

[libc++] Rename PS() macro to avoid clashing with Xtensa register name

This patch addresses a clash with the PS register from Xtensa
defined in the <specreg.h> header file, which is commonly included in
OS implementation.

Issue identified while building libc++ port for Apache NuttX, targeting
Xtensa-based chips (e.g. Espressif's ESP32).

Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>

Differential Revision: https://reviews.llvm.org/D122479

show more ...

[libc++] Fix double file closing in `std::filesystem::remove_all()`.

According to Linux documentation (see e.g. https://linux.die.net/man/3/closedir):

> A successful call to `closedir()` also close

[libc++] Fix double file closing in `std::filesystem::remove_all()`.

According to Linux documentation (see e.g. https://linux.die.net/man/3/closedir):

> A successful call to `closedir()` also closes the underlying file
> descriptor associated with `dirp`.

Thus, calling `close()` after a successful call to `closedir()` is at
best redundant. Worse, should a different thread open a file in-between
the calls to `closedir()` and `close()` and get the same file descriptor,
the call to `close()` might actually close a different file than was
intended.

rdar://89251874

Differential Revision: https://reviews.llvm.org/D120453

show more ...

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.

Differential Revision: https://reviews.llvm.org/D119769

show more ...

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/inclu

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/include/.

I've left `#include "include/x.h"` and `#include "../y.h"` alone
because I'm less sure that they're interchangeable, and they aren't
inconsistent with libcxx/include/ because libcxx/include/ never
does that kind of thing.

Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`,
even though it's technically unnecessary in a standalone .cpp file,
just so we have consistently one way to do it.

Differential Revision: https://reviews.llvm.org/D119561

show more ...

[libc++] Implement P0627R6 (Function to mark unreachable code)

Reviewed By: ldionne, Quuxplusone, #libc

Spies: arichardson, mstorsjo, libcxx-commits, mgorny

Differential Revision: https://reviews.

[libc++] Implement P0627R6 (Function to mark unreachable code)

Reviewed By: ldionne, Quuxplusone, #libc

Spies: arichardson, mstorsjo, libcxx-commits, mgorny

Differential Revision: https://reviews.llvm.org/D119152

show more ...

[libc++] Fix TOCTOU issue with std::filesystem::remove_all

https://bugs.chromium.org/p/llvm/issues/detail?id=19
rdar://87912416

Differential Revision: https://reviews.llvm.org/D118134