| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
`__tuple_types` is at this point just a `__type_list` with a weird name,
so we can just replace the few places it's still used.
|
|
We're only supporting Clang 20+ and Apple Clang 17 now, where these
builtins are universally implemented.
|
|
We've upgraded to LLVM 22 now, so we can remove a bunch of TODOs.
|
|
|
|
This essentially inlines `__make_tuple_types` and simplifies the support
code. This significantly simplifies the implementation, since
`__make_tuple_types` has multiple features, but the different places
that use it only make use of a subset of the features. Inlining it
separates concerns better and leads to less code in total.
|
|
(#154512)" (#155565)
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 72c04bb882ad70230bce309c3013d9cc2c99e9a7.
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 reverts commit af1f06e41b05c267480f1629dc0fcdf18f3b59f6.
This is causing some build failures in premerge as some of the LLDB
tests fail.
|
|
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 fixes a bug reported in
https://github.com/llvm/llvm-project/pull/151654#issuecomment-3205410955.
|
|
Implement P2255R2 tuple.apply part wording for `std::make_from_tuple`.
```
Mandates: If tuple_size_v<remove_reference_t<Tuple>> is 1, then reference_constructs_from_temporary_v<T, decltype(get<0>(declval<Tuple>()))> is false.
```
Fixes #154274
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
|
|
The SFINAE isn't required, since the primary `tuple` class already does
the SFINAE checks. This removes a bit of code that was only used for
these constraints.
This also moves the `tuple_element` specialization for `tuple` to
`__fwd/tuple.h` to avoid a dependency on `__tuple/sfinae_helpers.h`
(which should be moved in a follow-up).
|
|
And constrain the new `operator==` since C++26.
This patch implements parts of P2165R4, P2944R3, and a possibly improved
resolution of LWG3882. Currently, libstdc++ and MSVC STL constrain the
new overloads in the same way.
Also set feature-test macro `__cpp_lib_constrained_equality` and add
related release note, as P2944R3 will completed with this patch.
Fixes #136765
Fixes #136770
Fixes #105424
|
|
|
|
`__all_default_constructible` is never used, so we can remove it.
|
|
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.
|
|
Implements P2944R3 partially, which adds constrained comparisons
`std::tuple`.
The missing overloads introduced in [P2165R4](https://wg21.link/P2165R4)
are not implemented.
Uses
[`__all`](https://github.com/llvm/llvm-project/blob/f7af33a9eb5b3876f219075023dc9c565d75849b/libcxx/include/__type_traits/conjunction.h#L45)
instead of a fold expression, see comment:
https://github.com/llvm/llvm-project/pull/141396#discussion_r2161166077
Relates to #136765
# References
[tuple.rel](https://wg21.link//tuple.rel)
|
|
Currently, libc++'s `<tuple>` is using the deprecated
`__reference_binds_to_temporary` intrinsic. This PR starts to use
`__reference_constructs_from_temporary` if possible.
It seems that `__reference_constructs_from_temporary` should be used via
an internal type traits provided in
`<__type_traits/reference_constructs_from_temporary.h>`. But given the
old intrinsic was directly used, this PR doesn't switch to the current
convention yet.
P2255R2 is related. Although the paper indicated that constructors of
`tuple` should be deleted in such a case.
---------
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
|
|
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.
|
|
The need for `_LIBCPP_TEMPLATE_VIS` has been removed in #133233.
|
|
This patch removes all of the frozen headers which don't provide
anything. Basically any header that's C++11-or-later is removed from the
frozen headers.
This is part of
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.
|
|
|
|
This patch adds `[[_Clang::__no_specializations__]]` to `tuple`, with
warning/error suppressed for `tuple<>`.
|
|
(#121419)
Fixes #55474
|
|
Currently, when the result type is 1-`tuple`, `tuple_cat` possibly tests
an undesired constructor of the element, due to conversion from the
reference tuple to the result type. If the element type has an
unconstrained constructor template, there can be extraneous hard error
which shouldn't happen.
This patch introduces a helper function template to select the element-wise
constructor template of `tuple`, which can avoid such error.
Fixes #41034.
|
|
This significantly reduces the amount of debug information generated
for codebases using libc++, without hurting the debugging experience.
|
|
|
|
This makes the placement of the attribute more consistent. This also
avoids clang dropping the attribute silently (see #120722).
|
|
This patch implements the forwarding to frozen C++03 headers as
discussed in
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc. In the
RFC, we initially proposed selecting the right headers from the Clang
driver, however consensus seemed to steer towards handling this in the
library itself. This patch implements that direction.
At a high level, the changes basically amount to making each public
header look like this:
```
// inside <vector>
#ifdef _LIBCPP_CXX03_LANG
# include <__cxx03/vector>
#else
// normal <vector> content
#endif
```
In most cases, public headers are simple umbrella headers so there isn't
much code in the #else branch. In other cases, the #else branch contains
the actual implementation of the header.
|
|
Including The frozen C++03 headers results in a lot of formatting
changes in the main headers, so this splits these changes into a
separate commit instead.
This is part of
https://discourse.llvm.org/t/rfc-freezing-c-03-headers-in-libc.
|
|
|
|
This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.
|
|
This re-formats a few headers that had become out-of-sync with respect
to formatting since we ran clang-format on the whole codebase. There's
surprisingly few instances of it.
|
|
(#97401)
Implements: https://wg21.link/P2968R2
References:
- https://eel.is/c++draft/tuple.general
- https://eel.is/c++draft/tuple.syn
- https://eel.is/c++draft/tuple.creation
- https://github.com/cplusplus/draft/milestone/31
- https://github.com/cplusplus/draft/pull/7109
- https://github.com/cplusplus/papers/issues/1640
- https://cplusplus.github.io/LWG/issue2933
- https://cplusplus.github.io/LWG/issue3978
---------
Co-authored-by: Hristo Hristov <zingam@outlook.com>
|
|
keywords in C++11 code (#96387)
|
|
As time went by, a few files have become mis-formatted w.r.t.
clang-format. This was made worse by the fact that formatting was not
being enforced in extensionless headers. This commit simply brings all
of libcxx/include in-line with clang-format again.
We might have to do this from time to time as we update our clang-format
version, but frankly this is really low effort now that we've formatted
everything once.
|
|
This changes the `is_swappable` implementation to use variable templates
first and basing the class templates on that. This avoids instantiating
them when the `_v` versions are used, which are generally less resource
intensive.
|
|
Differential Revision: https://reviews.llvm.org/D121213
|
|
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
|
|
`__apply_cv_t` and `__copy_cvref_t` are very closely related. They are
in fact identical except that `__copy_cvref_t` handles rvalue references
properly. Some uses don't actually require handling of references, so
they are replaced with `__copy_cv_t`.
|
|
|
|
This moves the definition of a `pair` constructor for `<tuple>` to
`<__utility/pair.h>` and uses the forward declaration of `pair` in
`<tuple>` instead of including the definition.
|
|
of) a C-style cast) (#85263)
Implement [LWG3528](https://wg21.link/LWG3528).
Based on LWG3528(https://wg21.link/LWG3528) and
http://eel.is/c++draft/description#structure.requirements-9, the
standard allows to impose requirements, we constraint
`std::make_from_tuple` to make `std::make_from_tuple` SFINAE friendly
and also avoid worse diagnostic messages. We still keep the constraints
of `std::__make_from_tuple_impl` so that `std::__make_from_tuple_impl`
will have the same advantages when used alone.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
|
|
is{,_nothrow,_trivially}{,_copy,_move,_default}{_assignable,_constructible} (#85308)
These headers have become very small by using compiler builtins, often
containing only two declarations. This merges these headers, since
there doesn't seem to be much of a benefit keeping them separate.
Specifically, `is_{,_nothrow,_trivially}{assignable,constructible}` are
kept and the `copy`, `move` and `default` versions of these type traits
are moved in to the respective headers.
|
|
This also moves `tuple_size_v` into `tuple_size` as a drive-by.
|
|
This moves a utility from `<tuple>` into an implementation detail header
and refactors the selection of the variant index type to use.
|
|
We've talked about allowing extensions on
[discourse](https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/5)
and in a libc++ monthly meeting and agreed to test it out in the LLVM 18
release. We've done that with the `tuple` constructor overload set
(using conditional `explicit`). Since we haven't heard about any
breakages, it seems safe to do. This patch enables the use of extension
from later C++ standards inside the versioned `std` namespaces. This
should be good enough, since almost all of our code is inside that
namespace. This approach also avoids the use of extensions inside the
test `std` suite. That part of the code base should stay clean, since
it's a test suite that is also used by other vendors to test their
implementations.
|
|
Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
that mechanism anymore, we don't need to declare __libcpp_verbose_abort
from all public headers, and we can clean up a lot of unnecessary
includes.
This patch also moves the definition of the various assertion categories
to the <__assert> header, since we now rely on regular IWYU for these
assertion macros.
rdar://105510916
|
|
This brings the code base closer to having only a single style of
`enable_if`s.
|
