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

[libc++] Cache file attributes during directory iteration (#93316)

This patch adds caching of file attributes during directory iteration
on Windows. This improves the performance when working with

[libc++] Cache file attributes during directory iteration (#93316)

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.

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] Add `_LIBCPP_ASSERT_NON_NULL` to check for null pointers (#71428)

[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++] 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++] Make sure calls to std::move are always qualified

This fixes instances of the newly added `-Wunqualified-std-cast-call`.

(Commit 7853371146 removed unqualified `move` from the tests,
but t

[libc++] Make sure calls to std::move are always qualified

This fixes instances of the newly added `-Wunqualified-std-cast-call`.

(Commit 7853371146 removed unqualified `move` from the tests,
but these unqualified `move`s remained undetected in the actual headers.)

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

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++][NFC] Move some functions from directory_iterator.cpp to filesystem_common.h

This move is going to be needed in order to reuse `posix_readdir` in
another translation unit. This doesn't chang

[libc++][NFC] Move some functions from directory_iterator.cpp to filesystem_common.h

This move is going to be needed in order to reuse `posix_readdir` in
another translation unit. This doesn't change any of the code except
for removing an unused function parameter that otherwise triggers a
warning inside our tests.

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

show more ...

[libc++][NFC] Fix typo

[libc++] IWYU in <filesystem> tests

Add headers in `<filesystem>` tests that were transitively included
through `<filesystem>`

Reviewed as part of D116146

Revert "[libc++] Remove unused headers from <filesystem>"

This reverts commit 352945dd36c64fd68b4c73fcc393ee5828da639a.

[libc++] Remove unused headers from <filesystem>

Remove unused headers from `<filesystem>`

Spies: libcxx-commits

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

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...

[libc++] Improve src/filesystem's formatting of paths.

This is my attempt to merge D98077 (bugfix the format strings for
Windows paths, which use wchar_t not char)
and D96986 (replace C++ variadic t

[libc++] Improve src/filesystem's formatting of paths.

This is my attempt to merge D98077 (bugfix the format strings for
Windows paths, which use wchar_t not char)
and D96986 (replace C++ variadic templates with C-style varargs so that
`__attribute__((format(printf)))` can be applied, for better safety)
and D98065 (remove an unused function overload).

The one intentional functional change here is in `__create_what`.
It now prints path1 and path2 in square-brackets _and_ double-quotes,
rather than just square-brackets. Prior to this patch, it would
print either path double-quoted if-and-only-if it was the empty
string. Now the double-quotes are always present. I doubt anybody's
code is relying on the current format, right?

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

show more ...

[libcxx] Test accessing a directory on windows that gives "access denied" errors

Fix handling of skip_permission_denied on windows; after converting
the return value of GetLastError() to a standard

[libcxx] Test accessing a directory on windows that gives "access denied" errors

Fix handling of skip_permission_denied on windows; after converting
the return value of GetLastError() to a standard error_code, ec.value()
is in the standard errc range, not a native windows error code. This
was missed in 156180727d6c347eda3ba749730707acb8a48093.

The directory "C:\System Volume Information" does seem to exist and
have these properties on most relevant contempory setups.

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

show more ...

[libcxx] Fix the preexisting directory_iterator code for windows

The directory_iterator.cpp file did contain an incomplete,
non-working implementation for windows.

Change it to use the wchar versio

[libcxx] Fix the preexisting directory_iterator code for windows

The directory_iterator.cpp file did contain an incomplete,
non-working implementation for windows.

Change it to use the wchar version of the APIs.

Don't set the windows specific errors from GetLastError() as code
in the generic category; remap the errors to the std::errc values.

Error out cleanly on empty paths.

Invoke FindFirstFile on <directoryname>/* to actually list the
entries of the directory.

If the first entry retured by FindFirstFile is to be skipped (e.g.
being "." or ".."), call advance() (which calls FindNextFile and loops)
which doesn't return until a valid entry is found (or the end is
reached).

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

show more ...

[libc++] Fix directory_iterator compilation on Win32

This patch fixes some typos and other small errors in
directory_iterator.cpp that prevented this file from being compiled for
Win32.

Patch by St

[libc++] Fix directory_iterator compilation on Win32

This patch fixes some typos and other small errors in
directory_iterator.cpp that prevented this file from being compiled for
Win32.

Patch by Stefan Schmidt <thrimbor.github@gmail.com>!

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

llvm-svn: 370599

show more ...

Handle cases where the dirent::d_type macros aren't defined

llvm-svn: 352942

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that

Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351648

show more ...

Implement <filesystem>

This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.

Unlike other standard headers, the symbols needed for <filesystem>
have not

Implement <filesystem>

This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.

Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).

The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).

Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.

In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.

llvm-svn: 338093

show more ...