summaryrefslogtreecommitdiff
path: root/libcxx/test/support
AgeCommit message (Collapse)Author
2025-11-14[libc++][hardening] Allow setting the assertion semantic via CMake. (#167636)Konstantin Varlamov
Add a new CMake variable, `LIBCXX_ASSERTION_SEMANTIC`, that largely mirrors `LIBCXX_HARDENING_MODE`, except that it also supports a special value `hardening_dependent` that indicates the semantic will be selected based on the hardening mode in effect: - `fast` and `extensive` map to `quick_enforce`; - `debug` maps to `enforce`.
2025-11-13[libc++] Add an initial modulemap for the test support headers (#162800)Nikolas Klauser
This should improve the time it takes to run the test suite a bit. Right now there are only a handful of headers in the modulemap because we're missing a lot of includes in the tests. New headers should be added there from the start, and we should fill up the modulemap over time until it contains all the test support headers.
2025-11-10[libc++] Avoid overloaded `operator,` for (`T`, `Iter`) cases (#161049)A. Jiang
Several components in libc++ aren't defending against overloaded `operator,(T, Iter)` currently. Existing deleted overloads in `test_iterators.h` are insufficient for such cases. This PR adds corresponding deleted overloads with reversed order and fixes these libc++ components. - `piecewise_linear_distribution`'s iterator pair constructor, - `piecewise_linear_distribution::param_type`'s iterator pair constructor, - `piecewise_constant_distribution`'s iterator pair constructor, - `piecewise_constant_distribution::param_type`'s iterator pair constructor, - `money_get::do_get`, - `money_put::do_put`, and - `num_put::do_put`.
2025-11-09[libc++] Treat P0513R0 as a defect report against C++11 (#166690)A. Jiang
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.
2025-10-30[libc++] Fix localization failures on macOS 15.4 (#138744)Louis Dionne
This patch reverts e15025dd and 88e15b781 which were temporary measures until we had figured out the underlying issues. It turns out that recent OSes updated localization data, removing the need for several Apple-specific workarounds in the tests. Fixes #135385
2025-10-30[libc++] Fix LLVM 22 TODOs (#153367)Nikolas Klauser
We've upgraded to LLVM 22 now, so we can remove a bunch of TODOs.
2025-10-22[libc++][C++03] Introduce LIBCPP_{,NON_}FROZEN_ASSERT (#163380)Nikolas Klauser
There are a few cases where test only fail with the C++03 frozen headers because some implementation details are asserted. This patch introduces new assertion macros to differentiate between frozen and non-frozen headers.
2025-10-09[libc++] Remove availability annotations that aren't required anymore (#161640)Nikolas Klauser
Apple dropped support for some older platforms, so we can also remove the annotations for them. See https://developer.apple.com/support/xcode/ for the supported versions.
2025-09-30[libc++][test] Use ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS in more places ↵Martin Storsjö
(#144339) ASSERT_WITH_LIBRARY_INTERNAL_ALLOCATIONS allows waiving asserts, for cases when we can't count allocations that happen within the libc++ shared library. When compiling with optimization, it is possible that some calls end up generated inline, where the overridden operator new/delete do get called (counting those calls), whereas the compiler may decide to leave some calls to the external definition (inside the shared library, where we can't count the calls). In particular, in one case, a non-optimized build calls _ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev from the DLL, while it gets inlined (including direct calls to operator delete) when built with optimization. Therefore; for the cases where we can't count allocations internally within the library, waive these asserts. This fixes all testcases in mingw mode, when built with optimization enabled.
2025-09-15[libc++][test] Clean-up `MinSequenceContainer` (#158432)A. Jiang
Follows-up #158344. - Guard range-related functions with `TEST_STD_VER >= 23`. - Mark range-related functions unconditionally `constexpr`. - Add `TEST_CONSTEXPR_CXX20` to one `operator=`. This will make `MinSequenceContainer` more consistent and useful for legacy container adaptors or C++26 `constexpr` additions. Although we're currently only using it with flat container adaptors.
2025-09-14[libc++][test] update `MinSequenceContainer.h` to make one more test pass on ↵Alex Guteniev
MSVC STL (#158344) Continues #140287 `from_range_t` constructor is needed by MSVC STL to pass `std/containers/container.adaptors/flat.set/flat.set.cons/range.pass.cpp`. The rest are added to complete the container according to https://github.com/llvm/llvm-project/pull/140287#pullrequestreview-2848573089.
2025-09-08[libc++] Optimize most of the __tree search algorithms (#155245)Nikolas Klauser
This patch introduces a new comparator, namely `__lazy_synth_three_way`, which tries to provide an efficient three way comparator for known types and falls back to using the provided comparator if it doesn't know how to do that. Currently, an efficient three way comparison is only provided when using one of the `less` comparions object from the standard library and `std::string`. This will be extended in future patches. ``` ------------------------------------------------------------------------------------------------------------------------------ Benchmark old new ------------------------------------------------------------------------------------------------------------------------------ std::map<std::string, int>::ctor(const&)/0 12.6 ns 12.6 ns std::map<std::string, int>::ctor(const&)/32 858 ns 837 ns std::map<std::string, int>::ctor(const&)/1024 46700 ns 46739 ns std::map<std::string, int>::ctor(const&)/8192 458100 ns 449806 ns std::map<std::string, int>::ctor(iterator, iterator) (unsorted sequence)/0 12.8 ns 12.7 ns std::map<std::string, int>::ctor(iterator, iterator) (unsorted sequence)/32 1286 ns 1266 ns std::map<std::string, int>::ctor(iterator, iterator) (unsorted sequence)/1024 93812 ns 84686 ns std::map<std::string, int>::ctor(iterator, iterator) (unsorted sequence)/8192 1480346 ns 1385924 ns std::map<std::string, int>::ctor(iterator, iterator) (sorted sequence)/0 12.9 ns 12.8 ns std::map<std::string, int>::ctor(iterator, iterator) (sorted sequence)/32 1044 ns 1055 ns std::map<std::string, int>::ctor(iterator, iterator) (sorted sequence)/1024 63071 ns 62861 ns std::map<std::string, int>::ctor(iterator, iterator) (sorted sequence)/8192 595046 ns 590223 ns std::map<std::string, int>::operator=(const&) (into cleared Container)/0 13.6 ns 13.6 ns std::map<std::string, int>::operator=(const&) (into cleared Container)/32 880 ns 911 ns std::map<std::string, int>::operator=(const&) (into cleared Container)/1024 48627 ns 47808 ns std::map<std::string, int>::operator=(const&) (into cleared Container)/8192 458552 ns 454497 ns std::map<std::string, int>::operator=(const&) (into partially populated Container)/0 13.8 ns 13.6 ns std::map<std::string, int>::operator=(const&) (into partially populated Container)/32 864 ns 851 ns std::map<std::string, int>::operator=(const&) (into partially populated Container)/1024 49483 ns 49555 ns std::map<std::string, int>::operator=(const&) (into partially populated Container)/8192 456977 ns 457894 ns std::map<std::string, int>::operator=(const&) (into populated Container)/0 1.31 ns 1.31 ns std::map<std::string, int>::operator=(const&) (into populated Container)/32 425 ns 415 ns std::map<std::string, int>::operator=(const&) (into populated Container)/1024 14248 ns 14225 ns std::map<std::string, int>::operator=(const&) (into populated Container)/8192 136684 ns 133696 ns std::map<std::string, int>::insert(value) (already present)/0 21.5 ns 16.2 ns std::map<std::string, int>::insert(value) (already present)/32 22.7 ns 25.1 ns std::map<std::string, int>::insert(value) (already present)/1024 54.5 ns 29.1 ns std::map<std::string, int>::insert(value) (already present)/8192 78.4 ns 30.4 ns std::map<std::string, int>::insert(value) (new value)/0 40.9 ns 39.0 ns std::map<std::string, int>::insert(value) (new value)/32 58.3 ns 47.2 ns std::map<std::string, int>::insert(value) (new value)/1024 120 ns 71.3 ns std::map<std::string, int>::insert(value) (new value)/8192 157 ns 129 ns std::map<std::string, int>::insert(hint, value) (good hint)/0 40.3 ns 40.7 ns std::map<std::string, int>::insert(hint, value) (good hint)/32 48.0 ns 30.0 ns std::map<std::string, int>::insert(hint, value) (good hint)/1024 107 ns 63.2 ns std::map<std::string, int>::insert(hint, value) (good hint)/8192 132 ns 107 ns std::map<std::string, int>::insert(hint, value) (bad hint)/0 27.0 ns 40.9 ns std::map<std::string, int>::insert(hint, value) (bad hint)/32 68.3 ns 58.4 ns std::map<std::string, int>::insert(hint, value) (bad hint)/1024 125 ns 82.0 ns std::map<std::string, int>::insert(hint, value) (bad hint)/8192 155 ns 150 ns std::map<std::string, int>::insert(iterator, iterator) (all new keys)/0 404 ns 405 ns std::map<std::string, int>::insert(iterator, iterator) (all new keys)/32 2004 ns 1805 ns std::map<std::string, int>::insert(iterator, iterator) (all new keys)/1024 102820 ns 76102 ns std::map<std::string, int>::insert(iterator, iterator) (all new keys)/8192 1144590 ns 949266 ns std::map<std::string, int>::insert(iterator, iterator) (half new keys)/0 408 ns 404 ns std::map<std::string, int>::insert(iterator, iterator) (half new keys)/32 1592 ns 1377 ns std::map<std::string, int>::insert(iterator, iterator) (half new keys)/1024 74847 ns 53921 ns std::map<std::string, int>::insert(iterator, iterator) (half new keys)/8192 828505 ns 698716 ns std::map<std::string, int>::insert(iterator, iterator) (product_iterator from same type)/0 407 ns 407 ns std::map<std::string, int>::insert(iterator, iterator) (product_iterator from same type)/32 1584 ns 1557 ns std::map<std::string, int>::insert(iterator, iterator) (product_iterator from same type)/1024 47157 ns 47443 ns std::map<std::string, int>::insert(iterator, iterator) (product_iterator from same type)/8192 623887 ns 628385 ns std::map<std::string, int>::insert(iterator, iterator) (product_iterator from zip_view)/0 405 ns 403 ns std::map<std::string, int>::insert(iterator, iterator) (product_iterator from zip_view)/32 1478 ns 1510 ns std::map<std::string, int>::insert(iterator, iterator) (product_iterator from zip_view)/1024 47852 ns 47835 ns std::map<std::string, int>::insert(iterator, iterator) (product_iterator from zip_view)/8192 605311 ns 606951 ns std::map<std::string, int>::erase(key) (existent)/0 129 ns 94.0 ns std::map<std::string, int>::erase(key) (existent)/32 110 ns 106 ns std::map<std::string, int>::erase(key) (existent)/1024 121 ns 128 ns std::map<std::string, int>::erase(key) (existent)/8192 165 ns 66.9 ns std::map<std::string, int>::erase(key) (non-existent)/0 0.269 ns 0.257 ns std::map<std::string, int>::erase(key) (non-existent)/32 21.9 ns 11.3 ns std::map<std::string, int>::erase(key) (non-existent)/1024 53.5 ns 25.4 ns std::map<std::string, int>::erase(key) (non-existent)/8192 67.3 ns 31.9 ns std::map<std::string, int>::erase(iterator)/0 46.3 ns 46.7 ns std::map<std::string, int>::erase(iterator)/32 44.4 ns 41.8 ns std::map<std::string, int>::erase(iterator)/1024 43.7 ns 46.4 ns std::map<std::string, int>::erase(iterator)/8192 45.2 ns 44.1 ns std::map<std::string, int>::erase(iterator, iterator) (erase half the container)/0 407 ns 407 ns std::map<std::string, int>::erase(iterator, iterator) (erase half the container)/32 876 ns 906 ns std::map<std::string, int>::erase(iterator, iterator) (erase half the container)/1024 20880 ns 20444 ns std::map<std::string, int>::erase(iterator, iterator) (erase half the container)/8192 252881 ns 241583 ns std::map<std::string, int>::clear()/0 407 ns 408 ns std::map<std::string, int>::clear()/32 1252 ns 1323 ns std::map<std::string, int>::clear()/1024 38488 ns 38017 ns std::map<std::string, int>::clear()/8192 416492 ns 428534 ns std::map<std::string, int>::find(key) (existent)/0 0.008 ns 0.008 ns std::map<std::string, int>::find(key) (existent)/32 33.9 ns 15.3 ns std::map<std::string, int>::find(key) (existent)/1024 43.0 ns 25.5 ns std::map<std::string, int>::find(key) (existent)/8192 44.6 ns 29.3 ns std::map<std::string, int>::find(key) (non-existent)/0 0.259 ns 0.257 ns std::map<std::string, int>::find(key) (non-existent)/32 22.6 ns 11.4 ns std::map<std::string, int>::find(key) (non-existent)/1024 48.6 ns 25.1 ns std::map<std::string, int>::find(key) (non-existent)/8192 64.1 ns 31.1 ns std::map<std::string, int>::count(key) (existent)/0 0.008 ns 0.008 ns std::map<std::string, int>::count(key) (existent)/32 32.2 ns 17.3 ns std::map<std::string, int>::count(key) (existent)/1024 42.4 ns 25.3 ns std::map<std::string, int>::count(key) (existent)/8192 44.4 ns 31.6 ns std::map<std::string, int>::count(key) (non-existent)/0 0.260 ns 0.259 ns std::map<std::string, int>::count(key) (non-existent)/32 22.9 ns 11.3 ns std::map<std::string, int>::count(key) (non-existent)/1024 49.8 ns 25.5 ns std::map<std::string, int>::count(key) (non-existent)/8192 66.3 ns 31.9 ns std::map<std::string, int>::contains(key) (existent)/0 0.008 ns 0.008 ns std::map<std::string, int>::contains(key) (existent)/32 31.4 ns 18.0 ns std::map<std::string, int>::contains(key) (existent)/1024 44.3 ns 26.5 ns std::map<std::string, int>::contains(key) (existent)/8192 47.4 ns 30.2 ns std::map<std::string, int>::contains(key) (non-existent)/0 0.452 ns 0.441 ns std::map<std::string, int>::contains(key) (non-existent)/32 23.1 ns 11.5 ns std::map<std::string, int>::contains(key) (non-existent)/1024 46.2 ns 26.3 ns std::map<std::string, int>::contains(key) (non-existent)/8192 63.4 ns 31.4 ns std::map<std::string, int>::lower_bound(key) (existent)/0 0.008 ns 0.008 ns std::map<std::string, int>::lower_bound(key) (existent)/32 17.2 ns 19.0 ns std::map<std::string, int>::lower_bound(key) (existent)/1024 27.1 ns 26.2 ns std::map<std::string, int>::lower_bound(key) (existent)/8192 34.0 ns 36.0 ns std::map<std::string, int>::lower_bound(key) (non-existent)/0 0.259 ns 0.257 ns std::map<std::string, int>::lower_bound(key) (non-existent)/32 11.6 ns 11.5 ns std::map<std::string, int>::lower_bound(key) (non-existent)/1024 24.8 ns 25.6 ns std::map<std::string, int>::lower_bound(key) (non-existent)/8192 31.7 ns 31.6 ns std::map<std::string, int>::upper_bound(key) (existent)/0 0.008 ns 0.008 ns std::map<std::string, int>::upper_bound(key) (existent)/32 18.8 ns 19.7 ns std::map<std::string, int>::upper_bound(key) (existent)/1024 25.3 ns 27.7 ns std::map<std::string, int>::upper_bound(key) (existent)/8192 30.2 ns 29.9 ns std::map<std::string, int>::upper_bound(key) (non-existent)/0 0.260 ns 0.259 ns std::map<std::string, int>::upper_bound(key) (non-existent)/32 11.3 ns 12.0 ns std::map<std::string, int>::upper_bound(key) (non-existent)/1024 25.6 ns 25.9 ns std::map<std::string, int>::upper_bound(key) (non-existent)/8192 33.1 ns 34.2 ns std::map<std::string, int>::equal_range(key) (existent)/0 0.008 ns 0.008 ns std::map<std::string, int>::equal_range(key) (existent)/32 33.5 ns 15.8 ns std::map<std::string, int>::equal_range(key) (existent)/1024 43.0 ns 25.1 ns std::map<std::string, int>::equal_range(key) (existent)/8192 54.1 ns 30.7 ns std::map<std::string, int>::equal_range(key) (non-existent)/0 0.265 ns 0.259 ns std::map<std::string, int>::equal_range(key) (non-existent)/32 22.1 ns 12.1 ns std::map<std::string, int>::equal_range(key) (non-existent)/1024 44.8 ns 24.4 ns std::map<std::string, int>::equal_range(key) (non-existent)/8192 62.2 ns 40.1 ns ``` Fixes #66577
2025-09-04[libc++][NFC] Use llvm.org/PR to link to bug reports (#156288)Nikolas Klauser
We've built up quite a few links directly to github within the code base. We should instead use `llvm.org/PR<issue-number>` to link to bugs, since that is resilient to the bug tracker changing in the future. This is especially relevant for tests linking to bugs, since they will probably be there for decades to come. A nice side effect is that these links are significantly shorter than the GH links, making them much less of an eyesore. This patch also replaces a few links that linked to the old bugzilla instance on llvm.org.
2025-08-09[libc++] Fix uses of non-empty transparent comparator in `<map>` (#152624)A. Jiang
The `__get_value()` member function was removed in LLVM 21, but the calls in `<map>` weren't removed. This patch completes the removal and adds regression test cases. Fixes #152543.
2025-07-31[libc++][hardening] Add a greppable prefix to assertion messages. (#150560)Konstantin Varlamov
The current assertion failure messages produced by Hardening are not very grep-friendly (the common part is rarther generic and requires wildcards to match). While it's possible to use `__FILE__` for grepping, it's easier and more straighforward to simply add a libc++-specific prefix; this is especially important for the planned `observe` mode that might produce many assertion failure messages over the course of the program's execution that later need to be filtered and examined.
2025-07-29[libc++][hardening] Introduce assertion semantics. (#149459)Konstantin Varlamov
Assertion semantics closely mimic C++26 Contracts evaluation semantics. This brings our implementation closer in line with C++26 Library Hardening (one particular benefit is that using the `observe` semantic makes adopting hardening easier for projects).
2025-07-15Revert "[libc++][hardening] Introduce assertion semantics" (#148822)Nikolas Klauser
Reverts llvm/llvm-project#148268 It looks like this was based on #148266, which I reverted in #148787.
2025-07-15[libc++][hardening] Introduce assertion semantics (#148268)Konstantin Varlamov
Assertion semantics closely mimic C++26 Contracts evaluation semantics. This brings our implementation closer in line with C++26 Library Hardening (one particular benefit is that using the `observe` semantic makes adopting hardening easier for projects).
2025-07-05[libc++] Granularize <locale> (#146650)Nikolas Klauser
2025-06-25[libc++] P2944R3: Constrained comparisions - `variant` (#141396)Hristo Hristov
This is a follow-up and depends on #139368 being merged first. Implements [P2944R3](https://wg21.link/P2944R3) partially, which adds constrained comparisons to `std::variant` Closes #136769 Depends on #139368 # References [variant.relops](https://wg21.link/variant.relops)
2025-06-21[libc++] constexpr flat_map (#137453)Hui
Fixes #128673
2025-06-18[libc++] Make list constexpr as part of P3372R3 (#129799)Peng Liu
This patch makes `std::list` constexpr as part of P3372R3. Fixes #128659.
2025-06-17Revert "[libc++] Remove trailing newline from _LIBCPP_ASSERTION_HANDLER ↵Daniel Thornburgh
calls" (#144615) Reverts llvm/llvm-project#143573
2025-06-17[libc++] Remove trailing newline from _LIBCPP_ASSERTION_HANDLER calls (#143573)Sam Clegg
This newline was originally added in https://reviews.llvm.org/D142184 but I think updating `__libcpp_verbose_abort` to add newline instead is more consistent, and works for other callers of `_LIBCPP_VERBOSE_ABORT`. The `_LIBCPP_ASSERTION_HANDLER` calls through to either `_LIBCPP_VERBOSE_ABORT` macro or the `__builtin_verbose_trap`. From what I can tell neither of these function expect a trailing newline (at least none of the usage of `_LIBCPP_VERBOSE_ABORT` or `__builtin_verbose_trap` that I can find include a trailing newline except `_LIBCPP_ASSERTION_HANDLER`). I noticed this discrepancy when working on https://github.com/emscripten-core/emscripten/pull/24543
2025-06-15[libc++] P2944R3: Constrained comparisons - update `reference_wrapper` ↵Hristo Hristov
implementation (#139368) 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>
2025-06-11[libc++] Make forward_list constexpr as part of P3372R3 (#129435)Peng Liu
Fixes #128658
2025-06-09libc++ test: update MinSequenceContainer.h to make some tests pass on MSVC ↵Alex Guteniev
STL (#140287) Per [sequence.reqmts] there are these member functions. I did not audit if any other member functions are missing. Adding these is enough for MSVC STL
2025-06-02[libc++] Remove availability annotations which can't fire anymore (#140049)Nikolas Klauser
According to https://developer.apple.com/support/xcode/ the removed annotations can't fire anymore, since the targets they would fire for aren't supported anymore.
2025-05-19[libc++] Optimize std::getline (#121346)Nikolas Klauser
``` ----------------------------------------------- Benchmark old new ----------------------------------------------- BM_getline_string 318 ns 32.4 ns ```
2025-05-18[libc++] Don't instantiate allocators in __tree on an incomplete type (#140225)Nikolas Klauser
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`.
2025-05-06[libc++][test] Test `flat_meow` with proper underlying iterators (#131290)A. Jiang
Flat container adaptors require the iterators of underlying containers to be random access, and it is required that random access container iterators must support three-way comparison ([container.reqmts]/39 - /41). As a result, we should at least avoid testing "containers" with random access but not three-way comparable iterators for flat container adaptors. This patch adds a new class template `three_way_random_access_iterator` to `test_iterators.h` and fixes some usages of `MinSequenceContainer` with the new iterators.
2025-04-25[libcxx] [test] Clarify the condition for long double hex formatting (#135334)Martin Storsjö
This test currently hardcodes which environments have got 80 bit long doubles on x86_64 with a suitable printf formatting; convert the architecture check into a check specifically for 80 bit long doubles. Not all x86_64 configurations do have 80 bit long doubles (e.g. Android doesn't), and i386 configurations can also have 80 bit long doubles, compatible with this test. Also clarify the exact reasons for why specific OSes such as FreeBSD are skipped for these tests, even though they have 80 bit long doubles.
2025-04-13[libc++][test] Test `nasty_string` in C++20 (#135338)A. Jiang
It seems that we can only rely on C++20 features and make `nasty_string` also tested for MSVC STL.
2025-04-09[libc++] P3247R2: Deprecate `is_trivial(_v)` (#130573)A. Jiang
Requirements on character-like types are updated unconditionally, because `basic_string` does requires the default-constructibility. It might be possible to make `basic_string_view` support classes with non-public trivial default constructor, but this doesn't seem sensible. libcxxabi's `ItaniumDemangle.h` is also updated to avoid deprecated features.
2025-04-05[libc++] Implement ranges::iota (#68494)James E T Smith
# Overview As a disclaimer, this is my first PR to LLVM and while I've tried to ensure I've followed the LLVM and libc++ contributing guidelines, there's probably a good chance I missed something. If I have, just let me know and I'll try to correct it as soon as I can. This PR implements `std::ranges::iota` and `std::ranges::out_value_result` outlined in [P2440r1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2440r1.html). As outlined in the paper above, I've: - Implemented `out_value_result` and added to `<algorithm>` - Added `out_value_result`, `iota_result`, and two overloads of `iota` to `std::ranges` in `<numeric>` - Updated the version macro `__cpp_lib_ranges_iota` in `<version>` I've also added tests for `ranges::iota` and `ranges::out_value_result`. Lastly, I added those structs to the appropriate module files. Partially implements #105184 EDIT: Forgot to mention in the original post, thanks to @hawkinsw for taking a look at a preliminary version of this PR! # TODOs - [x] Updating the range [status doc](https://github.com/jamesETsmith/llvm-project/blob/main/libcxx/docs/Status/RangesMajorFeatures.csv) - [x] Ensure all comments from https://reviews.llvm.org/D121436 are addressed here - [X] EDIT (I'll do this in a separate PR). ~~I'm open to implementing the rest of P2440r1 (`ranges::shift_left` and `ranges::shift_right`) if that's ok, I just wanted to get feedback on `ranges::iota` first~~ - [x] I've been having trouble building the modules locally and want to make sure that's working properly Closes: #134060
2025-03-24[libc++][test][NFC] Introduce `TEST_STD_AT_LEAST_26_OR_RUNTIME_EVALUATED` ↵A. Jiang
(#132593) And use it for test cases that became constant-evaluation-suitable due to P2562R1. `TEST_STD_AT_LEAST_(20|23)_OR_RUNTIME_EVALUATED` are the precedents.
2025-03-20[libc++][test] Fix issues found by MSVC's STL (#131787)Stephan T. Lavavej
* libcxx/test/support/min_allocator.h + Fix `tiny_size_allocator::rebind` which mistakenly said `T` instead of `U`. * libcxx/test/std/algorithms/alg.modifying.operations/alg.partitions/stable_partition.pass.cpp + `std::stable_partition` requires bidirectional iterators. * libcxx/test/std/containers/sequences/vector.bool/max_size.pass.cpp + Fix allocator type given to `std::vector<bool>`. The element types are required to match, [N5008](https://isocpp.org/files/papers/N5008.pdf) \[container.alloc.reqmts\]/5: "*Mandates:* `allocator_type::value_type` is the same as `X::value_type`." * libcxx/test/std/time/time.clock/time.clock.utc/types.compile.pass.cpp + Mark `is_steady` as `[[maybe_unused]]`, as it appears within `LIBCPP_STATIC_ASSERT` only. * libcxx/test/std/algorithms/alg.modifying.operations/alg.rotate/rotate.pass.cpp * libcxx/test/std/algorithms/alg.modifying.operations/alg.swap/swap_ranges.pass.cpp * libcxx/test/std/utilities/utility/utility.swap/swap_array.pass.cpp + Fix MSVC warning C4127 "conditional expression is constant". `TEST_STD_AT_LEAST_23_OR_RUNTIME_EVALUATED` was introduced for this purpose, so it should be used consistently. * libcxx/test/std/numerics/numeric.ops/numeric.ops.gcd/gcd.pass.cpp + Fix `gcd()` precondition violation for `signed char`. This test case was causing `-128` to be passed as a `signed char` to `gcd()`, which is forbidden. * libcxx/test/std/containers/sequences/array/assert.iterators.pass.cpp * libcxx/test/std/containers/sequences/vector/vector.modifiers/assert.push_back.invalidation.pass.cpp * libcxx/test/std/input.output/iostream.format/print.fun/no_file_description.pass.cpp + Split some REQUIRES and XFAIL lines. This is a "nice to have" for MSVC's internal test harness, which is extremely simple and looks for exact comment matches to skip tests. We can recognize the specific lines "REQUIRES: has-unix-headers" and "XFAIL: msvc", but it's a headache to maintain if they're chained with other conditions. * libcxx/test/support/sized_allocator.h + Fix x86 truncation warnings. `std::allocator` takes `std::size_t`, so we need to `static_cast`. * libcxx/test/std/input.output/file.streams/fstreams/ifstream.members/offset_range.pass.cpp + Fix x86 truncation warning. `std::min()` is returning `std::streamoff`, which was being unnecessarily narrowed to `std::size_t`. * libcxx/test/std/algorithms/alg.sorting/alg.merge/inplace_merge_comp.pass.cpp + Fix MSVC warning C4127 "conditional expression is constant" for an always-true branch. This was very recently introduced by #129008 making `N` constexpr. As it's a local constant just nine lines above, we don't need to test whether 100 is greater than 0.
2025-03-19[libc++] Implement part of P2562R1: constexpr `std::inplace_merge` (#129008)A. Jiang
Drive-by: - Adds `constexpr_random.h` for pseudo-randomizing or shuffling in tests for constant evaluation.
2025-03-18[libc++] Guard call_once against operator hijacking. (#128054)Mark de Wever
2025-03-07[libc++] Implement part of P2562R1: constexpr `ranges::stable_sort` (#128860)A. Jiang
Drive-by: Enables test coverage for `ranges::stable_sort` with proxy iterators, and changes "constexpr in" to "constexpr since" in comments in `<algorithm>`.
2025-02-28[libcxx] Provide locale conversions to tests through lit substitution (#105651)Martin Storsjö
There are 2 problems today that this PR resolves: libcxx tests assume the thousands separator for fr_FR locale is x00A0 on Windows. This currently fails when run on newer versions of Windows (it seems to have been updated to the new correct value of 0x202F around windows 11. The exact windows version where it changed doesn't seem to be documented anywhere). Depending the OS version, you need different values. There are several ifdefs to determine the environment/platform-specific locale conversion values and it leads to maintenance as things change over time. This PR includes the following changes: - Provide the environment's locale conversion values through a substitution. The test can opt in by placing the substitution value in a define flag. - Remove the platform ifdefs (the swapping of values between Windows, Linux, Apple, AIX). This is accomplished through a lit feature action that fetches the environment's locale conversions (lconv) for members like 'thousands_sep' that we need to provide. This should ensure that we don't lose the effectiveness of the test itself. In addition, as a result of the above, this PR: - Fixes a handful of locale tests which unexpectedly fail on newer Windows versions. - Resolves 3 XFAIL FIX-MEs. Originally submitted in https://github.com/llvm/llvm-project/pull/86649. Co-authored-by: Rodrigo Salazar <4rodrigosalazar@gmail.com>
2025-02-23[libc++] Fix basic_string not allowing max_size() elements to be stored ↵Nikolas Klauser
(#125423) Without this patch `basic_string` cannot be properly resized to be `max_size()` elements in size, even if an allocation is successful. `__grow_by` allocates one less element than required, resulting in an out-of-bounds access. At the same time, `max_size()` has an off-by-one error, since there has to be space to store the null terminator, which is currently ignored.
2025-02-22[libc++] Fix shrink_to_fit to swap buffer only when capacity is strictly ↵Peng Liu
smaller (#127321) The current implementation of the `shrink_to_fit()` function of `basic_string` swaps to the newly allocated buffer when the new buffer has the same capacity as the existing one. While this is not incorrect, it is truly unnecessary to swap to an equally-sized buffer. With equal capacity, we should keep using the existing buffer and simply deallocate the new one, avoiding the extra work of copying elements. The desired behavior was documented in the following comment within the function: https://github.com/llvm/llvm-project/blob/61ad08792a86e62309b982189a600f4342a38d91/libcxx/include/string#L3560-L3566 However, the existing implementation did not exactly conform to this guideline, which is a QoI matter. This PR modifies the `shrink_to_fit()` function to ensure that the buffer is only swapped when the new allocation is strictly smaller than the existing one. When the capacities are equal, the new buffer will be discarded without copying the elements. This is achieved by including the `==` check in the above conditional logic.
2025-02-15[libc++] Fixes (|multi)_set spaceship operator. (#127326)Mark de Wever
The operators did not have a _Compare template arguement. The fix updates the generic container test to use allocators for all types used. No other issues were found. Fixes: #127095
2025-02-08[libc++][test] Fix `size_type` issues with `MinSequenceContainer` and ↵A. Jiang
`min_allocator` (#126267) `MinSequenceContainer::size` can be narrowing on 64-bit platforms, and MSVC complains about such implicit conversion. This PR changes the implicit conversion to explicit `static_cast`. `min_allocator::allocate` and `min_allocator::deallocate` have `ptrdiff_t` as the parameter type, which seems weird, because the underlying `std::allocator`'s member functions take `size_t`. It seems better to use `size_t` consistently.
2025-02-06[libc++][chrono] implements TAI clock. (#125550)Mark de Wever
Implements parts of: - P0355 Extending <chrono> to Calendars and Time Zones - P1361 Integration of chrono with text formatting - LWG3359 <chrono> leap second support should allow for negative leap seconds
2025-02-05[libc++] Fix UB in bitwise logic of {std, ranges}::{fill, fill_n} algorithms ↵Peng Liu
(#122410) This PR addresses an undefined behavior that arises when using the `std::fill` and `std::fill_n` algorithms, as well as their ranges counterparts `ranges::fill` and `ranges::fill_n`, with `vector<bool, Alloc>` that utilizes a custom-sized allocator with small integral types.
2025-01-24[libc++] Switch experimental library macros to 0/1 macros (#124030)Nikolas Klauser
This is a continuation of what's been started in #89178. As a drive-by, this also changes the PSTL macro to say `EXPERIMENTAL` instead of `INCOMPLETE`.
2025-01-08[libcxx] Handle windows system error code mapping in std::error_code. (#93101)James Y Knight
The `std::error_code`/`std::error_category` functionality is designed to support multiple error domains. On Unix, both system calls and libc functions return the same error codes, and thus, libc++ today treats `generic_category()` and `system_category()` as being equivalent. However, on Windows, libc functions return `errno.h` error codes in the `errno` global, but system calls return the very different `winerror.h` error codes via `GetLastError()`. As such, there is a need to map the winerror.h error codes into generic errno codes. In libc++, however, the system_error facility does not implement this mapping; instead the mapping is hidden inside libc++, used directly by the std::filesystem implementation. That has a few problems: 1. For std::filesystem APIs, the concrete windows error number is lost, before users can see it. The intent of the distinction between std::error_code and std::error_condition is that the error_code return has the original (potentially more detailed) error code. 2. User-written code which calls Windows system APIs requires this same mapping, so it also can also return error_code objects that other (cross-platform) code can understand. After this commit, an `error_code` with `generic_category()` is used to report an error from `errno`, and, on Windows only, an `error_code` with `system_category()` is used to report an error from `GetLastError()`. On Unix, system_category remains identity-mapped to generic_category, but is never used by libc++ itself. The windows error code mapping is moved into system_error, so that conversion of an `error_code` to `error_condition` correctly translates the `system_category()` code into a `generic_category()` code, when appropriate. This allows code like: `error_code(GetLastError(), system_category()) == errc::invalid_argument` to work as expected -- as it does with MSVC STL. (Continued from old phabricator review [D151493](https://reviews.llvm.org/D151493))
2024-12-21[libc++][C++03] Use `__cxx03/` headers in C++03 mode (#109002)Nikolas Klauser
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.
generated by cgit v1.2.3 (git 2.25.1) at 2026-10-22 05:38:46 +0000