| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
code (#122769)
That macro was present in the original implementation of the
synchronization library, but it was never defined and so it's
effectively unused.
|
|
This was missed in 43ba97e7079525a9686e15a6963508dfbd493f81 (#111821)
when reindenting after
917ada35cd937ad4104dff89c48398bd796ba6b7 (#80007).
|
|
std::shared_mutex (#107876)
Holding the associated lock while calling notify_* on a
condition_variable is generally considered a pessimization, as the
notified thread might "instantly" wake up, notice that it can't acquire
the lock, and then goes back to sleep.
|
|
Currently, places where we call __libcpp_allocate must drop type
information on the ground even when they actually have such information
available. That is unfortunate since some toolchains and system
allocators are able to provide improved security when they know what
type is being allocated.
This is the purpose of http://wg21.link/p2719, where we introduce a new
variant of `operator new` which takes a type in its interface. A
different but related issue is that `std::allocator` does not honor any
in-class `T::operator new` since it is specified to call the global
`::operator new` instead.
This patch closes the gap to make it trivial for implementations that
provide typed memory allocators to actually benefit from that
information in more contexts, and also makes libc++ forward-compatible
with future proposals that would fix the existing defects in
`std::allocator`. It also makes the internal allocation API higher level
by operating on objects instead of operating on bytes of memory.
Since this is a widely-used function and making this a template could
have an impact on debug info sizes, I tried minimizing the number of
templated layers by removing `__do_deallocate_handle_size`, which was
easy to replace with a macro (and IMO this leads to cleaner code).
|
|
Providing the character that we failed on is helpful for figuring out
what's going wrong in the tzdb.
|
|
The isascii() function is not standard, so we should avoid relying on
the platform providing it, especially since it's easy to implement in
libc++ portably.
|
|
<locale> (#122168)
|
|
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 mechanism is preferable in environments like embedded since it
doesn't require special handling of the custom section.
This is a reland of https://github.com/llvm/llvm-project/pull/114961
which addresses the issue reported by downstream users. Specifically,
the two differences from the previous version are:
* The internal `symbol##_impl__` symbol in the Mach-O implementation is
annotated with `__attribute__((used))` to prevent LTO from deleting it
which we've seen in the previous version.
* `__is_function_overridden` is marked as `inline` so these symbols are
placed in a COMDAT (or fully inlined) to avoid duplicate symbol errors
which we've seen in the previous version.
|
|
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.
|
|
1. remove unused __default_buffer_alignment
2. two __try_allocate_from_chunk are same, put it together
This patch refactor some code in monotonic_buffer_resource.
|
|
Instead of requiring `uselocale()` as part of the base locale API,
define __locale_guard in the few places that need it directly, without
making __locale_guard part of the base API.
In practice, most mainstream platforms never used __locale_guard, so
they also didn't need to define uselocale(), and after this patch they
actually don't define it anymore.
|
|
This reverts commit 62bd10f7d18ca6f544286767cae2c9026d493888.
Breaks building with -flto=thin, see
https://github.com/llvm/llvm-project/pull/114961#issuecomment-2555754056
|
|
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.
|
|
This mechanism is preferable in environments like embedded since it
doesn't require special handling of the custom section.
|
|
API (#115752)
This patch reimplements the locale base support for Windows flavors in a
way that is more modules-friendly and without defining non-internal
names.
Since this changes the name of some types and entry points in the built
library, this is effectively an ABI break on Windows (which is
acceptable after checking with the Windows/libc++ maintainers).
|
|
That variable is not referenced anywhere anymore, so it can be removed.
|
|
The pointer safety functions were never implemented by anyone in a
non-trivial way, which lead us to removing them entirely from the
headers when they were removed in C++23. This also means that just about
nobody ever called these functions, especially not in production code.
Because of that, we expect there to be no references in the wild to the
functions in the dylib. Because of that, this patch removes the symbols
from the dylib.
|
|
This disables `readability-identifier-naming` for the source files,
since names don't have to by _Uglified in the source files. We currently
don't enforce clang-tidy in the source files, so this is only useful to
avoid a bunch of warnings when using an editor that shows the results of
clang-tidy.
|
|
(#115764)
The __atomic_base base class is only useful to conditionalize the
operations we provide inside std::atomic. It shouldn't be used directly
from other places in the library which can use std::atomic directly
instead.
Since we've granularized our includes, using std::atomic directly should
not make much of a difference compile-time wise.
This patch starts using std::atomic directly from other classes like
std::barrier and std::latch. Changing this shouldn't be an ABI break
since both classes have the same size and layout.
The benefits of this patch are isolating other parts of the code base
from implementation details of std::atomic and simplifying the mental
model for std::atomic's layers of implementation by making it clear that
__atomic_base is only an implementation detail of std::atomic.
|
|
|
|
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.
|
|
(#114596)
Our current locale base API is a mix of non-reserved system names that
we incorrectly (re)define and internal functions and macros starting
with __libcpp. This patch introduces a function-based internal interface
to isolate the rest of the code base from that mess, so that we can work
on refactoring how each platform implements the base API in subsequent
patches. This makes it possible to refactor how each platform implements
the base localization API without impacting the rest of the code base.
|
|
This is a follow-up to #89178. This updates the `<__config_site>`
macros.
|
|
|
|
(#114023)
This reverts commit ef44e4659878f2. The patch was originally reverted
because it was
deemed to introduce a performance regression for small inputs, however
it also fixed
a previous performance regression for larger inputs. So overall, this
patch is desirable.
|
|
Rename __libcpp_locale_guard to just __locale_guard, since there's no
reason for it to have __libcpp_ in its name -- it's just an internal
utility.
Also, define __locale_guard unconditionally of
_LIBCPP_LOCALE__L_EXTENSIONS, since that header is only used on Windows
(where it has a custom definition) or from bsd_locale_fallbacks.h, which
is only included when the L extensions are not provided.
|
|
Identifiers `clang` and `noescape` are not reserved by the C++ standard,
so perhaps we need to use the equivalent reserved forms.
Also changes the occurrences of that attribute to a macro, following the
convention for `[[_Clang::__lifetimebound__]]`.
Addresses
https://github.com/llvm/llvm-project/pull/91651#discussion_r1807852646.
|
|
again (#113310)
This allows a slightly smoother transition for people after #109151, as
requested on that PR.
|
|
Implements std::from_chars for float and double.
The implementation uses LLVM-libc to do the real parsing. Since this is
the first time libc++
uses LLVM-libc there is a bit of additional infrastructure code. The
patch is based on the
[RFC] Project Hand In Hand (LLVM-libc/libc++ code sharing)
https://discourse.llvm.org/t/rfc-project-hand-in-hand-llvm-libc-libc-code-sharing/77701
|
|
Make __libcpp_verbose_abort() noexcept (it is already noreturn), to
match std::terminate(). Clang's function effect analysis can use this to
ignore such functions as being beyond its scope. (See
https://github.com/llvm/llvm-project/pull/99656).
|
|
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 is a purely mechanical commit for fixing the indentation of the
runtimes' CMakeLists files after #80007. That PR didn't update the
indentation in order to make the diff easier to review and for merge
conflicts to be easier to resolve (for downstream changes).
This doesn't change any code, it only reindents it.
|
|
This patch always defines the cxx_shared, cxx_static & other top-level
targets. However, they are marked as EXCLUDE_FROM_ALL when we don't want
to build them. Simply declaring the targets should be of no harm, and it
allows other projects to mention these targets regardless of whether
they end up being built or not.
This patch basically moves the definition of e.g. cxx_shared out of the
`if (LIBCXX_ENABLE_SHARED)` and instead marks it as EXCLUDE_FROM_ALL
conditionally on whether LIBCXX_ENABLE_SHARED is passed. It then does
the same for libunwind and libc++abi targets. I purposefully avoided to
reformat the files (which now has inconsistent indentation) because I
wanted to keep the diff minimal, and I know this is an area of the code
where folks may have downstream diffs. I will re-indent the code
separately once this patch lands.
This is a reapplication of 79ee0342dbf0, which was reverted in
a3539090884c because it broke the TSAN and the Fuchsia builds.
Resolves #77654
Differential Revision: https://reviews.llvm.org/D134221
|
|
On Apple platforms, using system-libcxxabi as an ABI library wouldn't
work because we'd try to re-export symbols from libc++abi that the
system libc++abi.dylib might not have. Instead, only re-export those
symbols when we're using the in-tree libc++abi.
This does mean that libc++.dylib won't re-export any libc++abi symbols
when building against the system libc++abi, which could be fixed in
various ways. However, the best solution really depends on the intended
use case, so this patch doesn't try to solve that problem.
As a drive-by, also improve the diagnostic message when the user forgets
to set the LIBCXX_CXX_ABI_INCLUDE_PATHS variable, which would previously
lead to a confusing error.
Closes #104672
|
|
When the library was initially written, it was not built with hidden
visibility. In an attempt to reduce the number of symbols exported from
libc++, an explicit list of symbols to avoid exporting was passed to the
linker. This was only done on Apple platforms.
Since then, the library has moved on in several ways. First, we now
build with hidden visibility by default, so arbitrary symbols don't get
exported from the library for no reason. Second, we have proper
visibility control via source annotations, so we export exactly what we
want to, and we do that from the sources.
This patch removes the explicit list of symbols to avoid exporting from
the library, which at this point doesn't cover much anyways. The only
symbols we will now be exporting that we were not before are some
typeinfo names for implementation-detail types. While we technically
wouldn't have to export those (I don't think any user can get their
hands on those typeinfo names), that makes the library more consistent
on all platforms.
|
|
This reverts commit d4ffccfce103b01401b8a9222e373f2d404f8439, which
caused a performance regression that needs to be investigated further.
|
|
Rather than using the following sequence of calls:
```
fprintf(stderr, "...");
::abort();
```
We should use the following:
```
__libcpp_verbose_abort("...")
```
This simplifies the code and ensures the behavior is consistent across
all call sites.
|
|
LLVM libc can handle out-of-range errno values.
|
|
Closes #108741
|
|
It doesn't serve much of a purpose since we can easily put its contents
inside __config. Removing it simplifies the modulemap once we are trying
to create a single top-level module.
|
|
(#80455)
`[[__noreturn__]]` is now always available, so we can simply use the
attribute directly instead of through a macro.
|
|
Apparently, there are two almost identical implementations: one for
MachO and another one for ELF. The ELF bits somehow slipped while
https://github.com/llvm/llvm-project/pull/84573 was reviewed.
The particular implementation is identical to MachO case.
|
|
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.
|
|
|
|
Summary:
The `langinfo.h` header is a POSIX extension, so ideally we would be
able to build the C++ library without it. Currently the LLVM C library
doesn't support / provide it. This allows us to build the C++ library
with locales enabled. We can either disable it here, or just provide
stubs that do nothing as in
https://github.com/llvm/llvm-project/pull/106620.
|
