Context: Including `<__utility/cmp.h>` causes:
> cmp.h:25:1: error: Empty namespaces should be avoided. Move any checks
around the namespace instead.
[libcpp-avoid-empty-namespaces,-warnings-as-errors]
This has the benefit of consistent placement for these macros (outside
the namespace, not inside it). This, in turn, makes it more obvious that
the condition applies to the entire namespace scope. Compile times are
also reduced a bit, since the compiler doesn't have to open a namespace
just to close it again.
This is enforced with a clang-tidy check.
As a drive-by this also fixes a few macro comments.
This is a follow-up to #193045. This only drops `_LIBCPP_HIDE_FROM_ABI`
in a small part of the code base to make sure everything works as
expected. Once this has been in trunk for a while and there aren't any
problems, there will be larger follow-up patches to remove
`_LIBCPP_HIDE_FROM_ABI` throughout the code base.
`std::exchange` is helpful for simplifying move operations because we
can couple the resetting component with the move operation. This both
halves the number of necessary lines for each move, and also ensures we
haven't forgotten to reset the moved-from object. Since `std::exchange`
is a C++14 feature, we'll need to use `__exchange` for anything that's
from C++11.
This commit also applies `std::__exchange` to a some trivial use-cases
to show its utility. Applying this project-wide requires a census over
all of our types. It's hoped that this will start a community-wide
clean-up that happens over time.
As Tomasz pointed out on mattermost,
given
```cpp
template <class T>
struct MustBeInt {
static_assert(std::same_as<T, int>);
};
struct Poison {
template <class T>
constexpr auto operator()(T) const noexcept -> MustBeInt<T> {
return {};
}
};
std::cw<Poison{}>(std::cw<5>);
```
This should work according to the wording
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3978r3.pdf
```cpp
template<class... Args>
static constexpr decltype(auto) operator()(Args&&... args) noexcept(see below);
```
```
- Let call-expr be constant_wrapper<INVOKE (value, remove_cvref_t<Args>::value...)>{} if all types
in remove_cvref_t<Args>... satisfy constexpr-param and constant_wrapper<INVOKE (value, remove_-
cvref_t<Args>::value...)> is a valid type, otherwise let call-expr be INVOKE (value, std::forward<Args>(args)...).
- Constraints: call-expr is a valid expression.
- Effects: Equivalent to: return call-expr;
- Remarks: The exception specification is equivalent to noexcept(call-expr).
```
so basically the spec says, there are two cases
- constexpr-param case
- runtime case
and if constexpr-param case works, uses it, otherwise fallback to
runtime case if it is valid, otherwise substitution error.
In this case, `std::cw<5>` satisfy `constexpr-param`, and
`constant_wrapper<Poison{}(5)>` is valid , it should just work. however,
our implementation implemented the two cases in two overload
```cpp
template <class... _Args>
requires(__constexpr_param<remove_cvref_t<_Args>> && ...)
_LIBCPP_HIDE_FROM_ABI static constexpr auto __call(_Args&&...) noexcept
-> constant_wrapper<std::invoke(value, remove_cvref_t<_Args>::value...)> {
return {};
}
template <class... _Args>
_LIBCPP_HIDE_FROM_ABI static constexpr auto
__call(_Args&&... __args) noexcept(noexcept(std::invoke(value, std::forward<_Args>(__args)...)))
-> decltype(std::invoke(value, std::forward<_Args>(__args)...)) {
return std::invoke(value, std::forward<_Args>(__args)...);
}
```
The logic is that, both overloads use return type SFINAE and the
constexpr-param case's concept is more constrained so it will be picked
first if constexpr-param case works.
However, in this example, the second overload's return type SFINAE
causes a hard error by the `static_assert` in the user code.
The fix is simply constrain the second overload and not using return
type SFINAE so it short circuits if constexpr-param case is valid.
As a drive by, removed the internal helper function and directly make
the public interface `operator()` two overloads so that we can apply
`[[nodiscard]]` on the constexpr-param case
In #155245, we implemented an optimization to std::map and std::set
search operations. That optimization took advantage of something that is
guaranteed by the Standard, namely that the comparator provided to the
associative container is a valid strict weak ordering.
Sadly, some code in the wild did not satisfy this requirement, such as
Boost.ICL: boostorg/icl#51
Since this can have extremely tricky runtime consequences, this patch
introduces a temporary escape hatch for the LLVM 22 release that allows
reverting to the previous behavior. It also explicitly calls out the
change in the release notes, adds some regression tests and adds debug
mode support for catching some of these invalid predicates.
Fixes#183189
#175913 removed that `__builtin_assume_dereferenceable(ptr, 0)` implies
`ptr != nullptr`, which should allow us to use the builtin with LLVM 23.
This reverts commit 776c09c212.
`__builtin_assume_dereferenceable` currently implies that the pointer
given to it is non-null, even if the size is zero. This causes
miscompilations, since we consider [nullptr, nullptr) to be a valid
range.
Reverts llvm/llvm-project#167697
[P1789R3](https://isocpp.org/files/papers/P1789R3.pdf) was accepted for
C++26 through LWG motion 14 at the 2025 Kona meeting. This patch
implements it, along with tests and documentation changes.
Closes#167268
---------
Co-authored-by: Tsche <che@pydong.org>
`[[nodiscard]]` should be applied to functions where discarding the
return value is most likely a correctness issue.
- https://libcxx.llvm.org/CodingGuidelines.html
1. `hash<shared_ptr>`, `hash<unique_ptr>`, `std::integer_sequence<>`
etc.
2. Also implements fixes to
https://github.com/llvm/llvm-project/issues/169634 on the go (issues
discovered during current implementation)
---------
Co-authored-by: A. Jiang <de34@live.cn>
Co-authored-by: Hristo Hristov <zingam@outlook.com>
This is done in two ways:
1) `index_sequence_for` is back-ported as `__index_sequence_for`
2) Extra functions just to expand the parameter pack are replaced with
lambdas
https://wg21.link/#support
`[[nodiscard]]` should be applied to functions where discarding the
return value is most likely a correctness issue.
- https://libcxx.llvm.org/CodingGuidelines.html#apply-nodiscard-where-relevant
The following was implemented in this patch:
- [x] `<compare>`
- [x] `<corotine>`
- [x] `<initializer_list>`
- [x] Integer comparisons
---------
Co-authored-by: Hristo Hristov <zingam@outlook.com>
Co-authored-by: A. Jiang <de34@live.cn>
The Trivial Relocation feature has been removed from the C++26 working
draft. Based on discussions in Kona, it is unlikely that the
"replaceable" type concept will come back in the C++29 time frame.
Since we don't have a use for the type trait in the library at the
moment, remove the code associated to it. If we end up needing something
like it in the future, we can always add it back.
There is a tradition to use U.S. English spellings for APIs. For
example, it's uninitialized_fill and not uninitialised_fill,
specialization not specialisation, etcetera.
This specializes `__lazy_synth_three_way_comparator` to forward to
`__default_three_way_comparator` if the comparator desugars to
`__greater_tag`. This is the same as the desugaring to `__less_tag`
except that the sign has to be inverted.
This uses the new `__builtin_lt_synthesises_from_spaceship` builtin from
clang to use three way comparison for arbitrary user-defined types that
only provide a spaceship operator.
The original PR has been reverted because of an LLDB test failure. This
patch now works around the test failure by simply allowing the new
symbols to show up in a stack trace.
This reverts commit 72c04bb882.
Original commit message:
This patch replaces `__can_extract_key` with an overload set to try to
extract the key. This simplifies the code, since we don't need to have
separate overload sets for the unordered and associative containers. It
also allows extending the set of extraction cases more easily, since we
have a single place to define how the key is extracted.
This patch replaces `__can_extract_key` with an overload set to try to
extract the key. This simplifies the code, since we don't need to have
separate overload sets for the unordered and associative containers. It
also allows extending the set of extraction cases more easily, since we
have a single place to define how the key is extracted.
This has two benefits:
- It is less likely that the macro will be copy-pasted around when
unnecessary
- We can drop `_LIBCPP_HIDE_FROM_ABI` from any member functions once we
are able to make `_LIBCPP_HIDE_FROM_ABI` the default within libc++
The internal API is a lot more complicated than it actually needs to be.
This refactors the internal API to match the features and names of the
public one.
This patch does a few things:
- `__libcpp_is_signed_integer` and `__libcpp_is_unsigned_integer` are
refactored to be variable templates instead of class templates.
- the two traits are merged into a single header
`<__type_traits/integer_traits.h>`.
- `__libcpp_signed_integer`, `__libcpp_unsigned_integer` and
`__libcpp_integer` are moved into the same header.
- The above mentioned concepts are renamed to `__signed_integer`,
`__unsigned_integer` and `__signed_or_unsigned_integer` respectively.
This makes it clearer what the functions actually do. As a nice
side-effect it also avoids a function call. If the C++03 header split is
successful we could drop `__get_pair` entirely.
That type trait represents whether move-assigning an object is
equivalent to destroying it and then move-constructing a new one from
the same argument. This will be useful in a few places where we may want
to destroy + construct instead of doing an assignment, in particular
when implementing some container operations in terms of relocation.
This is effectively adding a library emulation of P2786R12's
is_replaceable trait, similarly to what we do for trivial relocation.
Eventually, we can replace this library emulation by the real
compiler-backed trait.
This is building towards #129328.
This patch makes instantiation of `pair` in CTAD a bit lazier to avoid
instantiating invalid `pair` specialization before the decaying explicit
deduction guide works.
This avoids instantiating multiple classes, reducing compile times. This
patch also introduces `__underyling_type_t` for internal use, similar to
other type traits.
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).
This allows forwarding an object as a specific type. This is usually
useful when using `deducing this` to avoid calling any functions in a
deriving class.
This disentangles the code which previously had a mix of many #ifdefs, a
non-versioned namespace and a versioned namespace. It also makes it
clearer which parts of <new> are implemented on Windows by including <new.h>.
