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.
Currently these two functions are constrained on `is_unsigned`, which is
more permissive than what is required by the standard for their public
counterparts. This fixes the constraints to match the public functions
by using `__libcpp_is_unsigned_integer` instead.
When localization is disabled, we used to skip testing a lot of headers.
However, these headers are now "no-ops" when localization is disabled,
so they can actually be included. As such, we should test their
inclusion in our usual header inclusion tests.
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.
The libc++ build includes a step where headers are generated. This is
required in order to preprocess some files such as the assertion handler
and the __config_site header. As a result, the library is built against
headers located inside the build directory, and the path to those
headers is what's included in the debug information of the library.
However, these headers in the build directory are usually not
persistent, which means that the debug information might end up
referring to headers that don't exist anymore. To solve this problem,
this patch uses the -fdebug-prefix-map flag supported by Clang and GCC
to remap the generated headers to the original headers in the source
directory. This provides the illusion that the library was truly built
against the in-source version of the headers.
This patch includes __fwd/span.h in <mdspan> so that we get the
declaration of dynamic_extent inside <mdspan>. We also clean up quite a
few tests that were manually included <span> for dynamic_extent.
This is based on feedback from #142693.
Reviewers: philnik777, ldionne
Reviewed By: philnik777
Pull Request: https://github.com/llvm/llvm-project/pull/142925
This is brought up in the LWG reflector. We currently call `reserve` if
the underlying container has one. But the spec does not specify what
`reserve` should do for Sequence Container. So in theory if the
underlying container is user defined type and it can have a function
called `reserve` which does something completely different.
The fix is to just call `reserve` for STL containers if it has one
See discussion in https://cplusplus.github.io/LWG/issue4239
std::flat_map<std::string, int, std::less<>> m;
m.try_emplace("abc", 5); // hard error
The reason is that we specify in 23.6.8.7 [flat.map.modifiers]/p21
the effect to be as if `ranges::upper_bound` is called.
`ranges::upper_bound` requires indirect_strict_weak_order, which
requires the comparator to be invocable for all combinations. In this
case, it requires
const char (&)[4] < const char (&)[4]
to be well-formed, which is no longer the case in C++26 after
https://wg21.link/P2865R6.
This patch uses `std::upper_bound` instead.
`_ITER_TRAITS` and `_ITER_CONCEPT` are really implenentation details of
`<__iterator/concetps.h>`, so it makes more sense to put them there than
into `<__iterator/iterator_traits.h>`.
The new FTM tests contain text that they validate against to check the
output of the FTM generation script. However, that text lexically
contains the characters `// UNSUPPORTED: <...>`, which leads Lit to make
the whole test unsupported under these conditions. To prevent that from
happening, an `# END.` block can be used to prevent Lit from looking
further into the file for directives.
This patch adds missing <span> includes for std::mdspan tests that use
std::span. There are other cases where we need dynamic_extent that are
handled in #142925.
This was found by running the test suite in the bootstrapping build
with Clang modules enabled.
Currently, when the string shrink into the SSO buffer, the `__rep_.__s`
member isn't activated before the `traits_type::copy` call
yet, so internal `__builtin_memmove` call writing to the buffer causes
constant evaluation failure. The existing test coverage seems a bit
defective and doesn't cover this case - `shrink_to_fit` is called on the
copy of string after erasure, not the original string object.
This PR reorders the `__set_short_size` call, which starts the lifetime
of the SSO buffer, before the copy operation. Test coverage is achieved
by calling `shrink_to_fit` on the original erased string.
The current implementation of `forward_list::resize` does not meet the
strong exception safety guarantee required by [forward.list.modifiers]:
If an exception is thrown by any of these member functions there is no
effect on the container.
This patch refactors `resize()` to provide strong exception safety and
introduces additional tests to validate the strong exception guarantees
for other `forward_list` modifiers.
Fixes#118366.
`common_reference` isn't an exception for [meta.rqmts]/4, so it's better
to disallow users to specialize it.
`indirectly_readable.compile.pass.cpp` was a bit problematic. It
attempted to opt-out common reference type in some wrong ways. Also, the
standard effectively forbids opting-out common reference type for `T&`
and `T&&`. This patch removes and adjusts some problematic cases.
---------
Co-authored-by: Nikolas Klauser <nikolasklauser@berlin.de>
#109028 caused `sizeof` to be sometimes applied to function reference
types, which makes a program ill-formed. This PR handles reference types
by specializations to prevent such bogus `sizeof` expression to be
instantiated.
Fixes#142118.
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>
The ABI bump to adopt the conforming ABI v1 std::pair implementation did
not end up happening for FreeBSD 14, and instead this diff was reverted
downstream in FreeBSD[1]. Align the upstream ABI config with FreeBSD's
actual ABI.
[1] ce4f1f49e036 ("Revert commit 6255157d24 from llvm-project (by
Dimitry Andric):")
This reverts commit 6255157d24.
I didn't entirely figure out what's going on here, but probably this
will be improved when clang implements constexpr structured bindings.
For now, just reach into the initializer of the holding variable and use
that.
Fixes#109 and #144.
The affected tests are relying on the fact that `MinSequenceContainer`
does not have `insert_range`. This prevents landing of #140287.
This PR creates a new helper class to allow the change in MinSequenceContainer.
Fixes#135351
This PR update CATD guides to associative containers (`std::map`,
`std::multimap`, `std::unordered_map`, `std::unordered_multimap`,
`std::flat_map`, `std::flat_multimap`).
- Updated template alias for deduction guides for the relevant
associative containers.
- Added a new test to verify the deduction guides with `std::map`,
`std::multimap`, `std::unordered_map`, `std::unordered_multimap`,
`std::flat_map`, `std::flat_multimap`.
This patch refactors the `all()` and `any()` methods in `bitset` to
eliminate redundant code while preserving the performance. Code
generation remains unchanged, as verified on Compiler
Explorer: https://godbolt.org/z/xx8hb4sPM.
This PR simplifies `__bitset::__init` into a more compact and readable
form, which avoids redundant computations of a `size_t` value and
eliminates the overhead of a local array.
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.
It turns out that we're about to revert the patches that added these
annotations in the first place. I was too hasty to land this.
This reverts commit 56594710c7.
We get an error "cannot add 'abi_tag' attribute in a redeclaration"
because functions like `__dispatch_apply` are first declared without an
ABI tag due to `_LIBCPP_BEGIN_EXPLICIT_ABI_ANNOTATIONS` inside the
header, and then redeclared with an ABI tag in the .cpp file.
