#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.
The underlying bug in vcruntime [1] has been fixed in the latest version
of MSVC (released two weeks ago); this will cause the test which is
currently marked XFAIL to start erroring, when it starts passing
unexpectedly.
This version of MSVC may soon start appearing in the Github Actions
runner images used for our CI.
We could try to detect the state of this bug, but in practice, such
detection code would essentially be a copy of this whole test.
Therefore, just mark this test UNSUPPORTED for the MSVC mode builds. If
we at some point require new enough MSVC libraries, we could remove the
marking entirely.
[1]
https://developercommunity.visualstudio.com/t/vcruntime-nothrow-array-operator-new-fal/10373274
We've added a new macro for the unversioned `namespace std` cases in
#133009, but it seems we've missed a few places. This fixes the places I
just found.
This patch optimizes `bitset::to_string` by replacing the existing bit-by-bit processing with a more efficient
bit traversal strategy. Instead of checking each bit sequentially, we leverage `std::__countr_zero` to efficiently
locate the next set bit, skipping over consecutive zero bits. This greatly accelerates the conversion process,
especially for sparse `bitset`s where zero bits dominate. To ensure similar improvements for dense `bitset`s, we
exploit symmetry by inverting the bit pattern, allowing us to apply the same optimized traversal technique. Even
for uniformly distributed `bitset`s, the proposed approach offers measurable performance gains over the existing
implementation.
Benchmarks demonstrate substantial improvements, achieving up to 13.5x speedup for sparse `bitset`s with
`Pr(true bit) = 0.1`, 16.1x for dense `bitset`s with `Pr(true bit) = 0.9`, and 8.3x for uniformly distributed
`bitset`s with `Pr(true bit) = 0.5)`.
This patch enhances the performance of `std::for_each_n` when used with
segmented iterators, leading to significant performance improvements,
summarized in the tables below. This addresses a subtask of
https://github.com/llvm/llvm-project/issues/102817.
This doesn't show up in the CI, since we don't have abilists for
windows. I'm also not sure whether we want them, so I don't think we can
easily test this change.
This generator has almost identical output to the existing script.
Notable differences are
- conditionally include headers that are not implemented yet
- removes the synopsis
- uses 2 spaces indent in `# if`
There are a few more test macros added that triggered bugs in existing
FTM.
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++.
This has been introduced by #134819, most likely due to a merge conflict
I didn't resolve properly (I thought I did in that patch what I'm now
doing here).
This causes a mismatch between `value_type` and
`allocator_type::value_type` in `__tree`, but I think that's acceptable.
`__tree` primarily gets a `__value_type` wrapper due to potential ABI
breaks and unwraps it to the same as `allocator_type::value_type` in the
end. A cleanup patch will also change `__tree::value_type` to be the
same as `allocator_type::value_type`, making the type mismatch only
visible where `__tree` is instantiated in `map`.
We currently don't have any ABI tags in our dylib symbols, and this is
unlikely to change in the future. By diagnosing this we avoid
accidentally adding one through e.g. having `_LIBCPP_HIDE_FROM_ABI` on
an exported symbol.
charN_t represent code units of different UTF encodings. Therefore the
values of 2 different charN_t objects do not represent the same
characters.
In order to avoid comparing apples and oranges, we add new warnings to
warn on:
- Implicit conversions
- Comparisons
- Other cases involving arithmetic conversions
We only produce the warning if we cannot establish the comparison would
be safe through constant evaluation.
The new `-Wimplicit-unicode-conversion` warning is enabled by default.
Note that this PR intentionally doesn;t touches char/wchar_t, but it
would be worth considering also warning on extending the new warnings to
these types (in a follow up)
Additionally most arithmetic operations on charN_t don't really make
sense (ie what does it mean to addition code units), so we could add
warnings for that.
Fixes#138526
This adds a new test to run clang-tidy on the `src/` directory and
temporarily disables and clang-tidy checks that currently fail. They
will be enabled in follow-up patches.
Before this patch, we were dereferencing pointers to objects which were
never constructed. Now we always assume that nodes store `pair<const
KeyT, ValueT>` for maps instead, as they actually do. This patch also
allows for significant follow-up simplifications, since
`__node_value_type` and `__container_value_type` are the same type now.
This patch adds missing benchmark coverage for partial_sort,
partial_sort_copy, is_sorted and is_sorted_until.
It also refactors the existing benchmarks for sort and stable_sort to
follow the consistent style of the new algorithm benchmarks. However,
these benchmarks were notoriously slow to run since they tested multiple
data patterns on multiple data types. To try to alleviate this, I
reduced the benchmarks to only run on integral types and on a single
non-integral type, which should faithfully show how the algorithm
behaves for anything non-integral. However, this is technically a
reduction in coverage.
This patch enhances the test coverage of `{std,ranges}::swap_ranges` by
adding larger test cases with 100 elements across different containers.
It also inlines standalone tests for better readability, avoiding
unnecessary navigation.
This patch addresses a follow-up suggestion from PR #121138 to extend
test coverage beyond 3 elements.
libc++ makes the `hash<vector<bool, A>>::operator()` `constexpr` since
C++20, which is a conforming extension, but it was unintended.
This patch removes the extension, with an escape hatch macro for it, and
the escape hatch will be removed in the future. Test cases for
`constexpr` along with the assumption of hash values are moved to the
`libcxx/test/libcxx/` subdirectory.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
