| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Since `__resize_default_init` is only ever used inside the dylib we can
remove the libc++-internal API and switch to the public one. This patch
inlines a bunch of functions that aren't required anymore and simplifies
the code that way.
|
|
`std::filesystem::path::lexically_relative` (#152964)
Improves runtime by around 20 to 40%. (1.3x to 1.7x)
```
Benchmark Time CPU Time Old Time New CPU Old CPU New
------------------------------------------------------------------------------------------------------------------------------------------------
BM_LexicallyRelative/small_path/2 -0.2111 -0.2082 229 181 228 180
BM_LexicallyRelative/small_path/4 -0.2579 -0.2550 455 338 452 337
BM_LexicallyRelative/small_path/8 -0.2643 -0.2616 844 621 838 619
BM_LexicallyRelative/small_path/16 -0.2582 -0.2556 1562 1158 1551 1155
BM_LexicallyRelative/small_path/32 -0.2518 -0.2496 3023 2262 3004 2254
BM_LexicallyRelative/small_path/64 -0.2806 -0.2775 6344 4564 6295 4549
BM_LexicallyRelative/small_path/128 -0.2165 -0.2137 11762 9216 11683 9186
BM_LexicallyRelative/small_path/256 -0.2672 -0.2645 24499 17953 24324 17891
BM_LexicallyRelative/large_path/2 -0.3268 -0.3236 426 287 422 285
BM_LexicallyRelative/large_path/4 -0.3274 -0.3248 734 494 729 492
BM_LexicallyRelative/large_path/8 -0.3586 -0.3560 1409 904 1399 901
BM_LexicallyRelative/large_path/16 -0.3978 -0.3951 2764 1665 2743 1659
BM_LexicallyRelative/large_path/32 -0.3934 -0.3908 5323 3229 5283 3218
BM_LexicallyRelative/large_path/64 -0.3629 -0.3605 10340 6587 10265 6564
BM_LexicallyRelative/large_path/128 -0.3450 -0.3423 19379 12694 19233 12649
BM_LexicallyRelative/large_path/256 -0.3097 -0.3054 36293 25052 35943 24965
```
---------
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
|
|
_LIBCPP_HIDE_FROM_ABI everywhere (#131156)" (#141756)
This reverts commit c861fe8a71e64f3d2108c58147e7375cd9314521.
Unfortunately, this use of hidden visibility attributes causes
user-defined specializations of standard-library types to also be marked
hidden by default, which is incorrect. See discussion thread on #131156.
...and also reverts the follow-up commits:
Revert "[libc++] Add explicit ABI annotations to functions from the block runtime declared in <__functional/function.h> (#140592)"
This reverts commit 3e4c9dc299c35155934688184319d391b298fff7.
Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)"
This reverts commit f73287e623a6c2e4a3485832bc3e10860cd26eb5.
Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)"
This reverts commit 1d411f27c769a32cb22ce50b9dc4421e34fd40dd.
|
|
_LIBCPP_HIDE_FROM_ABI everywhere (#131156)
This patch introduces `_LIBCPP_{BEGIN,END}_EXPLICIT_ABI_ANNOTATIONS`,
which allow us to have implicit annotations for most functions, and just
where it's not "hide_from_abi everything" we add explicit annotations.
This allows us to drop the `_LIBCPP_HIDE_FROM_ABI` macro from most
functions in libc++.
|
|
Adds missing includes that were detected when I tried to build libc++ as
a module.
Working towards #127012
|
|
We have `[[fallthrough]]` available in all standards modes, so we can
just inline it like other stanard attributes we use.
|
|
This is technically not necessary in most cases to prevent issues with ADL,
but let's be consistent. This allows us to remove the libcpp-qualify-declval
clang-tidy check, which is now enforced by the robust-against-adl clang-tidy check.
|
|
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))
|
|
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.
|
|
Fix for issues reported in https://github.com/llvm/llvm-project/pull/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.
|
|
clock_gettime is a POSIX API that may not be available on platforms like
baremetal; timespec_get is the C11 equivalent. This change adds support
for using timespec_get instead of clock_gettime to improve compatibility
with non-POSIX platforms. For now, this is only enabled with LLVM libc
which implemented timespec_get in #116102, but in the future this can be
expanded to other platforms.
Related to #84879.
|
|
|
|
The variables are all `constexpr`, which implies `inline`. Since they
aren't `constexpr` in C++03 they're also not `inline` there. Because of
that we define them out-of-line currently. Instead we can use the C++17
extension of `inline` variables, which results in the same weak
definitions of the variables but without having all the boilerplate.
|
|
This is a follow-up to #89178. This updates the `<__config_site>`
macros.
|
|
Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`_LIBCPP_HAS_NO_`. This patch changes that, so that they are always
defined and have the prefix `_LIBCPP_HAS_` instead. This changes the
canonical use of these macros to `#if _LIBCPP_HAS_FEATURE`, which means
that using an undefined macro (e.g. due to a missing include) is
diagnosed now. While this is rather unlikely currently, a similar change
in `<__configuration/availability.h>` caught a few bugs. This also
improves readability, since it removes the double-negation of `#ifndef
_LIBCPP_HAS_NO_FEATURE`.
The current patch only touches the macros defined in `<__config>`. If
people are happy with this approach, I'll make a follow-up PR to also
change the macros defined in `<__config_site>`.
|
|
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.
|
|
|
|
lexically_proximate and hash_value on Windows (#99780)
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.
|
|
Summary:
I am attempting to get the GPU to build and support libc++. One issue
I've encountered is that it will look for `timeval` unless this macro is
set. We can support `CLOCK_MONOTONIC` on the GPU fairly easily as we
have access to a fixed-frequency clock via `__builtin_readsteadycounter`
intrinsics with a known frequency. This also requires `CLOCK_REALTIME`
which we can't support, but provide anyway from the GPU `libc` to make
this happy. It will return an error so at least that will be obvious.
I may need a more consistent configuration for this in the future, maybe
I should put a common macro in a different common header that's just
`__GPU__`? I don't know where I would put such a thing however.
|
|
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.
|
|
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).
|
|
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.
|
|
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.
|
|
Introduce two new categories:
- `_LIBCPP_ASSERT_VALID_DEALLOCATION`;
- `_LIBCPP_ASSERT_VALID_EXTERNAL_API_CALL`.
|
|
(#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.
|
|
Also introduce `_LIBCPP_ASSERT_PEDANTIC` for assertions violating which
results in a no-op or other benign behavior, but which may nevertheless
indicate a bug in the invoking code.
|
|
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
|
|
<filesystem> is a C++17 addition. In C++11 and C++14 modes, we actually
have all the code for <filesystem> but it is hidden behind a non-inline
namespace __fs so it is not accessible. Instead of doing this unusual
dance, just guard the code for filesystem behind a classic C++17 check
like we normally do.
|
|
(#71428)
|
|
This avoids enabling them unconditionally in all hardening modes.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D158970
|
|
GNU/Hurd does have clock_gettime, it just doesn't define _POSIX_TIMERS because its support for timers is not complete.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D158584
|
|
Since we build the dylib with C++20, there's no need to use conditional
macros anymore.
Differential Revision: https://reviews.llvm.org/D157995
|
|
This patch moves a few tests that were still using std::fprintf to
using TEST_REQUIRE instead, which provides a single point to tweak
for platforms that don't implement fprintf. As a fly-by fix, it also
avoids including `time_utils.h` in filesystem_clock.cpp when it is
not required, since that header makes some pretty large assumptions
about the platform it is on.
Differential Revision: https://reviews.llvm.org/D155019
|
|
This patch partly reverts the change that was made in 5f1ba3a502
regarding the clock selection on Apple platforms. It turns out that
gettimeofday() is marked as obsolete by POSIX and clock_gettime() is
recommended instead. Since both are equivalent for our purposes,
prefer using clock_gettime() even on Apple platforms.
Differential Revision: https://reviews.llvm.org/D155022
|
|
Right now, the filesystem APIs _mostly_ use Win32 API calls, but a
small number of functions use CRT APIs instead. The semantics are
effectively the same, except for which sorts of error codes are
returned. We want to be consistent about returning only native Win32
error codes, as a prerequisite for https://reviews.llvm.org/D151493.
This change switches getcwd, chdir, and mkdir. It does _not_ switch
open/close, because there are difficulties around the use of C-runtime
file descriptor numbers. Instead, those two APIs are removed from
posix_compat.h, and the win32-specific code inlined into the
operations.cpp FileDescriptor class (with a TODO comment).
Reviewed By: #libc, mstorsjo, Mordante
Differential Revision: https://reviews.llvm.org/D153037
|
|
Note that _FilesystemClock will now be implemented by calling gettimeofday()
on Apple platforms instead of clock_gettime(). However, since both are
equivalent, this should not change the behavior on Apple platforms.
There should be no behavior change on other platforms.
In addition to being a consistency clean up, this fixes some issues seen
by folks as reported in https://reviews.llvm.org/D154390#4471924.
Differential Revision: https://reviews.llvm.org/D154457
|
|
The filesystem clock implementation should be available regardless of
whether a proper filesystem is available on the platform, so it makes
sense to try and avoid including things that are inherently filesystem-y
in the implementation of filesystem clock.
Differential Revision: https://reviews.llvm.org/D154390
|
|
__builtin_assume can sometimes worsen code generation. For now, the
guideline seems to be to avoid adding assumptions without a clear
optimization intent. Since _LIBCPP_ASSERT is very general, we can't
have a clear optimization intent at this level, which makes
__builtin_assume the wrong tool for the job -- at least until
__builtin_assume is changed.
See https://discourse.llvm.org/t/llvm-assume-blocks-optimization/71609
for a discussion of this.
Differential Revision: https://reviews.llvm.org/D153968
|
|
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
|
|
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
|
|
posix_compat.h uses struct timeval which is defined in <sys/time.h>
but it doesn't include it. On most POSIX platforms like Linux or macOS,
that headers is transitively included by other headers like <sys/stat.h>,
but there are other platforms where this is not the case.
Differential Revision: https://reviews.llvm.org/D153384
|
|
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
|
|
into _LIBCPP_EXPORTED_FROM_ABI
These macros are always defined identically, so we can simplify the code a bit by merging them.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, krytarowski, smeenai
Differential Revision: https://reviews.llvm.org/D152652
|
|
[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
|
|
This file was added before we started granularizing the headers, but is essentially just a granularized header. This moves the header to the correct place.
Reviewed By: #libc, EricWF
Spies: libcxx-commits, arichardson, mikhail.ramalho
Differential Revision: https://reviews.llvm.org/D146395
|
|
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D147853
|
|
This patch bumps the minimum macOS version for building the dylib
or back-deploying a statically-linked libc++ from macOS 10.11 to
macOS 10.13. AFAICT, Chrome was the last one to require macOS 10.11,
but since then they have bumped their minimal supported version to
macOS 10.13.
Differential Revision: https://reviews.llvm.org/D145012
|
|
Clang wants to enable this flag by default, but libc++ isn't working with it yet.
Reviewed By: Mordante, #libc, #libc_abi, EricWF
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D144667
|
|
Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits, smeenai
Differential Revision: https://reviews.llvm.org/D143163
|
