Papers:
- P0792R14: function_ref: a type-erased callable reference
- P3948R1 constant_wrapper is the only tool needed for passing constant
expressions via function arguments
- P3961R1 Less double indirection in function_ref (RU-220)
LWG issues:
- LWG4256: Incorrect constraints for function_ref constructors from
nontype_t
- LWG4425: CTAD function_ref of data member pointer should produce
noexcept signature
Fixes#189606Fixes#105376Fixes#189604Fixes#171321Fixes#171387
---------
Co-authored-by: Xiaoyang Liu <siujoeng.lau@gmail.com>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
The `std::function` members are incredibly simple to the point where
they are just wrappers around internal functions. We can inline them
into the body to simplify the implementation a bit.
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.
clang-tidy currently doesn't run in the CI because CMake doesn't find
the appropriate `ClangConfig.cmake` anymore. This adds the path so
clang-tidy is built again and fixes most issues. Some things are
disabled for now to get most checks back. They will be re-enabled later.
This patch introduces `_LIBCPP_{BEGIN/END}_EXPLICIT_ABI_ANNOTATIONS` and
marks everything within an
`_LIBCPP_{BEGIN,END}_UNVERSIONED_NAMESPACE_STD` (and any derivatives
like `_LIBCPP_{BEGIN,END}_NAMESPACE_STD`) implicitly by default. This
allows us to drop `_LIBCPP_HIDE_FROM_ABI` in most of the code base,
except for functions which shouldn't be `_LIBCPP_HIDE_FROM_ABI`.
This patch doesn't remove any `_LIBCPP_HIDE_FROM_ABI`s, since we have
over 13k of them in the code base. Actually dropping them will happen
over some time to avoid too many merge conflicts.
__is_transparent_v used to accept an additional _Key template argument
whose sole purpose was to make the instantiation as a whole dependent.
It turns out that creates confusion around whether that trait takes into
account the key type (it does not). Instead, we can use our traditional
approach for making template params artificially dependent, which allows
removing the confusing parameter.
For disclaimer, I authored this patch with Claude code just to see if I
could get it to do the right thing. It works, but you have to steer it
right.
Fixes#186417
Renaming from _Tp to _ArgumentType makes it clearer that we're passing
the argument type intended for the comparator, which allows checking
whether *that specific use* of the comparator would be transparent.
Fixes#186396
We already have `_PairT`, which is just a pair of two `size_t`s, so we
might as well use that throughout the file. This avoids the `pair`
include altogether, reducing header parse times a bit in some cases.
We're currently unwrapping `less<T>` even if the `key_type` isn't `T`.
This causes the removal of an implicit conversion to `const T&` if the
types mismatch. Making `less<T>` transparent in that case changes
overload resolution and makes it fail potentially.
Fixes#179319
`[[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
For `__has_result_type`, it can be replaced with a variable template
`__has_result_type_v`. Note that the pre-existing extraneous `*` used in
detection is buggy, but it's a functional change to fix it.
`false_type` and `true_type` are no longer directly used, so direct
inclusion of `<__type_traits/integral_constant.h>` is removed.
For `__derives_from_{unary,binary}_function`, it's unnecessary to invent
a `__two` type for each specialization. So `void` is used instead. Also,
`nullptr` is now used instead of `0`.
`[[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 functions/classes have been annotated in this patch:
- [x] `bind_back`, `bind_front`, `bind`
- [x] `function`, `mem_fn`
- [x] `reference_wrapper`
P0513R0 is essentially a collective resolution paper of LWG2543,
LWG2791, LWG2809, and LWG2817.
Among these LWG issues, LWG2543 (conditionally enabled `hash`) and
LWG2817 (`hash<nullptr_t>`) affect pre-C++17 utilities. We generally
backport changes from LWG issues, so this patch backports the relevant
parts of P0513R0.
Although we provide `hash<unique_ptr>` as an extension in C++03 mode, as
C++03 mode isn't encouraged now, this patch leaves `hash<unique_ptr>`
unchanged in C++03 mode.
This patch adds additional overloads to `map::at` in case its known that
the argument is transparently comparable to the key type. This avoids
actually constructing the key type in some cases, potentially removing
allocations.
```
--------------------------------------------------------
Benchmark old new
--------------------------------------------------------
BM_map_find_string_literal 12.8 ns 2.68 ns
```
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.
Fixes#105260
This patch applies the change as a DR to C++20. The rationale is that
the paper is more like a bug fix. It does not introduce new features, it
simply changes an existing behaviour (as a bug fix). MSVC STL DRed this
paper to C++20 as well.
The use-case for `__is_same_uncvref` seems rather dubious, since not a
single use-cases needed the `remove_cvref_t` to be applied to both of
the arguments. Removing the alias makes it clearer what actually
happens, since we're not using an internal name anymore and it's clear
what the `remove_cvref_t` should apply to.
`vector` has been used in a very simple way in `boyer_moore_searcher`.
We can instead just use `unique_ptr<T[]>`, which is a lot simpler,
allowing us to drop the `vector` dependency while not losing any
expressiveness in the code. As a nice side effect, this also reduces the
time it takes to instantiate the `boyer_moore_searcher` constructor from
26ms to 22ms on my machine.
Since we've removed allocator support, we can remove a few support
structures. This only affects the policy implementation, so this
shouldn't even be ABI sensitive.
Updates the implementation `std::reference_wrapper` -
[P2944R3](https://wg21.link/P2944R3) as discussed in
https://github.com/llvm/llvm-project/pull/117664#discussion_r1857826166
This PR also refactors the tests in preparation to implements the
constrained comparisons for `optional`, `variant` etc.
- Moves the test helpers (concepts and types) for testing constrained
comparisons to `test_comparisons.h`.
- Updates the `std::reference_wrapper` implementation to use the concept
`__core_convertible_to<bool>` as per comments in #135759.
Closes#138233
# References:
- [refwrap.comparisons](https://wg21.link/refwrap.comparisons)
---------
Co-authored-by: Hristo Hristov <zingam@outlook.com>
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
The allocator support was removed in P0302R1, since it was impossible to
implement. We're currently providing the API for this, but ignore the
allocator in all cases but one (which is almost certainly an oversight).
That case is the `function(allocator_arg_t, const Alloc&, Func)`
constuctor. IMO we should remove the API entirely at a later date, but
this only removes most of the code for now, leaving only the public
functions. This not only simplifies the code quite a bit, but also
results in the constructor being instantiated ~8x faster.
Fixes#133901
Instead of providing full specializations of `hash` for every arithmetic
type, this moves the implementation to a base class, which is
specialized via `enable_if`s instead.
This reverts commit c861fe8a71.
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 3e4c9dc299.
Revert "[libc++] Make ABI annotations explicit for windows-specific code (#140507)"
This reverts commit f73287e623.
Revert "[libc++][NFC] Replace a few "namespace std" with the correct macro (#140510)"
This reverts commit 1d411f27c7.
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++.
We're currently adding `bad_function_call::what()` behind an ABI flag,
even though adding it is not an ABI break and can be handled through
availability.
This avoids instantiating multiple classes, reducing compile times. This
patch also introduces `__underyling_type_t` for internal use, similar to
other type traits.
This has multiple benefits:
- There is a single instance of our hash function, reducing object file
size
- The hash implementation isn't instantiated in every TU anymore,
reducing compile times
- Behind an ABI configuration macro it would be possible to salt the
hash
Previously, const and ref qualification on an operation would cause
__desugars_to to report false, which would lead to unnecessary
pessimizations. The same holds for reference_wrapper.
In practice, const and ref qualifications on the operation itself are
not relevant to determining whether an operation desugars to something
else or not, so can be ignored.
We are not stripping volatile qualifiers from operations in this patch
because we feel that this requires additional discussion.
Fixes#129312
Recent Clang-21 builds improved the deprecated diagnotics. This
uncovered missing guards in libc++ internally.
Note: This patch should be a separate commit and not merged.
For testing purposes they are combined.
Reviewed as part of #130497.
This set usage of operator& instead of std::addressof seems not be easy
to "abuse". Some seem easy to misuse, like basic_ostream::operator<<,
trying to do that results in compilation errors since the `widen`
function is not specialized for the hijacking character type. Hence
there are no tests.
