[libc++] Remove some private symbols from the ABI (#121497)

These symbols are never referenced directly outside the dylib, so we can
make them hidden instead. They are still in the dylib since can

[libc++] Remove some private symbols from the ABI (#121497)

These symbols are never referenced directly outside the dylib, so we can
make them hidden instead. They are still in the dylib since can be
referenced through the `memory_resource*`, but dynamic linkers don't
have to do any work to deduplicate them.

show more ...

[libc++] Pass type information down to __libcpp_allocate (#118837)

Currently, places where we call __libcpp_allocate must drop type
information on the ground even when they actually have such infor

[libc++] Pass type information down to __libcpp_allocate (#118837)

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

show more ...

[libc++] Refactor some code in monotonic_buffer_resource (#117271)

1. remove unused __default_buffer_alignment
2. two __try_allocate_from_chunk are same, put it together

This patch refactor some

[libc++] Refactor some code in monotonic_buffer_resource (#117271)

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.

show more ...

[libc++] Refactor the configuration macros to being always defined (#112094)

This is a follow-up to #89178. This updates the `<__config_site>`
macros.

[libc++] Granularize <cstddef> includes (#108696)

[libc++][RFC] Always define internal feature test macros (#89178)

Currently, the library-internal feature test macros are only defined if
the feature is not available, and always have the prefix
`

[libc++][RFC] Always define internal feature test macros (#89178)

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

show more ...

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

[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 more assertions. (#75918)

Also introduce `_LIBCPP_ASSERT_PEDANTIC` for assertions violating which
results in a no-op or other benign behavior, but which may neverthel

[libc++][hardening] Categorize more assertions. (#75918)

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.

show more ...

[libc++][hardening] Add `_LIBCPP_ASSERT_NON_NULL` to check for null pointers (#71428)

[libc++] Change _LIBCPP_CONSTEXPR_SINCE_XXX to constexpr in the dylib

Since we build the dylib with C++20, there's no need to use conditional
macros anymore.

Differential Revision: https://reviews.

[libc++] Change _LIBCPP_CONSTEXPR_SINCE_XXX to constexpr in the dylib

Since we build the dylib with C++20, there's no need to use conditional
macros anymore.

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

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++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI

These macros are always defined identically, so we can simplify the code a bit by merging t

[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI 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

show more ...

[libc++][CI] Switches to clang-format-16.

Uses an absolute path to the selected binary.
Updates the formatting of two files to match clang-format-16 style.

Depends on D144126

Reviewed By: #libc, p

[libc++][CI] Switches to clang-format-16.

Uses an absolute path to the selected binary.
Updates the formatting of two files to match clang-format-16 style.

Depends on D144126

Reviewed By: #libc, philnik

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

show more ...

[libc++] Make pmr::monotonic_buffer_resource bump down

Bumping down is significantly faster than bumping up. This is ABI breaking, but the ABI of `pmr::monotonic_buffer_resource` was only stabilized

[libc++] Make pmr::monotonic_buffer_resource bump down

Bumping down is significantly faster than bumping up. This is ABI breaking, but the ABI of `pmr::monotonic_buffer_resource` was only stabilized in this release cycle, so we can still change it.
For a more detailed explanation why bumping down is better, see https://fitzgeraldnick.com/2019/11/01/always-bump-downwards.html.

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

show more ...

[libc++][PMR] Move the pmr::memory_resource destructor into the dylib

This avoids emitting the VTable of `pmr::memory_resource` in every TU.

Reviewed By: ldionne

Spies: EricWF, nemanjai, libcxx-co

[libc++][PMR] Move the pmr::memory_resource destructor into the dylib

This avoids emitting the VTable of `pmr::memory_resource` in every TU.

Reviewed By: ldionne

Spies: EricWF, nemanjai, libcxx-commits

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

show more ...

[libc++] Add the C++17 <memory_resource> header (mono-patch)

This patch is the rebase and squash of three earlier patches.
It supersedes all three of them.

- D47111: experimental monotonic_buffer_r

[libc++] Add the C++17 <memory_resource> header (mono-patch)

This patch is the rebase and squash of three earlier patches.
It supersedes all three of them.

- D47111: experimental monotonic_buffer_resource.
- D47358: experimental pool resources.
- D47360: Copy std::experimental::pmr to std::pmr.

The significant difference between this patch and the-sum-of-those-three
is that this patch does not add `std::experimental::pmr::monotonic_buffer_resource`
and so on. This patch simply adds the C++17 standard facilities, and
leaves the `std::experimental` namespace entirely alone.

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

show more ...