Commit Graph

5212 Commits

Author SHA1 Message Date
Hongyu Ouyang
37f9036320
[libc++] Make drop_view::begin constant time (#72883) (#72929)
As pointed out in #72883, the implementation only needs to return the
value of ranges::next and does not need to obtain the value through
ranges::advance, which causes it to have O(n) complexity in the case
of random-access-sized but non-common range.

Fixes #72883
2023-12-28 21:27:42 +00:00
Nikolas Klauser
50ae0da058
[libc++][NFC] Refactor <experimental/simd> a bit to simplify dependencies (#76283) 2023-12-24 08:50:01 +01:00
Nikolas Klauser
eeeb963841
[libc++] Use __datasizeof for __libcpp_datasizeof if available (#72104)
This avoids the UB and makes things a bit cheaper in terms of
compile-times.
2023-12-24 08:45:25 +01:00
Nikolas Klauser
b203d5320d
[libc++] Optimize std::find if types are integral and have the same signedness (#70345)
Fixes #70238
2023-12-23 11:21:27 +01:00
Tacet
82b38e83cf
[ASan][libc++] Optimization of container annotations (#76082)
This commit implements conditional compilation for ASan helper code.

As convey to me by @EricWF, string benchmarks with UBSan have been
experiencing significant performance hit after the commit with ASan
string annotations. This is likely due to the fact that no-op ASan code
is not optimized out with UBSan. To address this issue, this commit
conditionalizes the inclusion of ASan helper function bodies using
`#ifdef` directives. This approach allows us to selectively include only
the ASan code when it's actually required, thereby enhancing
optimizations and improving performance.

While issue was noticed in string benchmarks, I expect same overhead
(just less noticeable) in other containers, therefore `std::vector` and
`std::deque` have same changes.

To see impact of that change run `string.libcxx.out` with UBSan and
`--benchmark_filter=BM_StringAssign` or
`--benchmark_filter=BM_StringConstruct`.
2023-12-21 17:26:10 -05:00
Konstantin Varlamov
1638657dce
[libc++][hardening] Categorize more 'valid-element-access' checks. (#71620) 2023-12-20 17:24:48 -08:00
Sanjay Marreddi
c37734d409
[libc++] Fix ability to explicitly instantiate std::midpoint (#74217)
std::midpoint is specified by having a pointer overload in
[numeric.ops.midpoint].
With the way the pointer overload is specified, users can expect that
calling
std::midpoint as `std::midpoint<T>(a, b)` should work, but it didn't in
libc++
due to the way the pointer overload was specified.

Fixes #67046
2023-12-20 11:53:19 +01:00
Christopher Di Bella
3903438860
[libcxx] adds ranges::fold_left_with_iter and ranges::fold_left (#75259)
Notable things in this commit:

* refactors `__indirect_binary_left_foldable`, making it slightly
different (but equivalent) to _`indirect-binary-left-foldable`_, which
improves readability (a [patch to the Working Paper][patch] was made)
* omits `__cpo` namespace, since it is not required for implementing
niebloids (a cleanup should happen in 2024)
* puts tests ensuring invocable robustness and dangling correctness
inside the correctness testing to ensure that the algorithms' results
are still correct

[patch]: https://github.com/cplusplus/draft/pull/6734
2023-12-19 21:57:50 -08:00
ZijunZhaoCCK
fdd089b500
[libc++] Implement ranges::contains (#65148)
Differential Revision: https://reviews.llvm.org/D159232
```
Running ./ranges_contains.libcxx.out
Run on (10 X 24.121 MHz CPU s)
CPU Caches:
  L1 Data 64 KiB (x10)
  L1 Instruction 128 KiB (x10)
  L2 Unified 4096 KiB (x5)
Load Average: 3.37, 6.77, 5.27
--------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
--------------------------------------------------------------------
bm_contains_char/16             1.88 ns         1.87 ns    371607095
bm_contains_char/256            7.48 ns         7.47 ns     93292285
bm_contains_char/4096           99.7 ns         99.6 ns      7013185
bm_contains_char/65536          1296 ns         1294 ns       540436
bm_contains_char/1048576       23887 ns        23860 ns        29302
bm_contains_char/16777216     389420 ns       389095 ns         1796
bm_contains_int/16              7.14 ns         7.14 ns     97776288
bm_contains_int/256             90.4 ns         90.3 ns      7558089
bm_contains_int/4096            1294 ns         1290 ns       543052
bm_contains_int/65536          20482 ns        20443 ns        34334
bm_contains_int/1048576       328817 ns       327965 ns         2147
bm_contains_int/16777216     5246279 ns      5239361 ns          133
bm_contains_bool/16             2.19 ns         2.19 ns    322565780
bm_contains_bool/256            3.42 ns         3.41 ns    205025467
bm_contains_bool/4096           22.1 ns         22.1 ns     31780479
bm_contains_bool/65536           333 ns          332 ns      2106606
bm_contains_bool/1048576        5126 ns         5119 ns       135901
bm_contains_bool/16777216      81656 ns        81574 ns         8569
```

---------

Co-authored-by: Nathan Gauër <brioche@google.com>
2023-12-19 16:34:19 -08:00
Mark de Wever
2fd4084fca
[libc++][print] Adds ostream overloads. (#73262)
Finishes implementation of
- P2093R14 Formatted output
- P2539R4 Should the output of std::print to a terminal be synchronized
with the underlying stream?

Differential Revision: https://reviews.llvm.org/D156609
2023-12-19 19:32:17 +01:00
Louis Dionne
5b57da32a8 [libc++] Fix nolint comment that became useless after running clang-format 2023-12-18 17:49:21 -05:00
A. Jiang
1821bc1e96
[libc++] Fix the handling of views::take for iota_view (#75683)
Currently, when libc++'s views::take specially handles an iota_view, the
addition is done after dereferencing the beginning iterator. However, in
[range.take.overview]/2.3, the addition is done before the dereferencing,
which means that the standard requires the returned iota_view to have
the same W and Bound type in such cases.

This patch fixes that, and also fixes a test that was testing the 
incorrect behavior.

Fixes #75611
2023-12-18 15:41:14 -05:00
Louis Dionne
9783f28cbb
[libc++] Format the code base (#74334)
This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

   find libcxx/include libcxx/src -type f \
      | grep -v 'module.modulemap.in' \
      | grep -v 'CMakeLists.txt' \
      | grep -v 'README.txt' \
      | grep -v 'libcxx.imp' \
      | grep -v '__config_site.in' \
      | xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
2023-12-18 14:01:33 -05:00
Louis Dionne
a35629cd8d
[libc++] Remove assumptions that std::array::iterator is a raw pointer (#74624)
This patch removes assumptions that std::array's iterators are raw
pointers in the source code and in our test suite. While this is true
right now, this doesn't have to be true and ion the future we might want
to enable bounded iterators in std::array, which would require this
change.

This is a pre-requisite for landing #74482
2023-12-18 10:00:47 -05:00
Mark de Wever
9c18f03196
[libc++] Adds headers to FTM. (#75699)
These feature-test macros had no headers listed in their associated
papers. This adds the expected headers.

Fixes https://github.com/llvm/llvm-project/issues/75577
2023-12-18 12:43:10 +01:00
Louis Dionne
70bcd81e7a
[libc++] Fix constexpr initialization of std::array<T, 0> (#74667)
This patch fixes constexpr default initialization of empty arrays and
improves the tests accordingly.

Fixes #74375
2023-12-15 16:06:12 -05:00
Nikolas Klauser
f7407411a1
[libc++] Optimize std::find for segmented iterators (#67224)
```
--------------------------------------------------------------------------
Benchmark                                              old             new
--------------------------------------------------------------------------
bm_find<std::deque<char>>/1                        6.06 ns         10.6 ns
bm_find<std::deque<char>>/2                        15.5 ns         10.6 ns
bm_find<std::deque<char>>/3                        19.0 ns         10.6 ns
bm_find<std::deque<char>>/4                        20.8 ns         10.6 ns
bm_find<std::deque<char>>/5                        22.0 ns         10.6 ns
bm_find<std::deque<char>>/6                        23.0 ns         10.5 ns
bm_find<std::deque<char>>/7                        24.8 ns         10.7 ns
bm_find<std::deque<char>>/8                        25.7 ns         10.6 ns
bm_find<std::deque<char>>/16                       28.3 ns         10.6 ns
bm_find<std::deque<char>>/64                       44.2 ns         27.0 ns
bm_find<std::deque<char>>/512                       133 ns         37.6 ns
bm_find<std::deque<char>>/4096                      867 ns         53.1 ns
bm_find<std::deque<char>>/32768                    6838 ns          160 ns
bm_find<std::deque<char>>/262144                  52897 ns         1495 ns
bm_find<std::deque<char>>/1048576                215621 ns         6077 ns
bm_find<std::deque<short>>/1                       6.03 ns         6.28 ns
bm_find<std::deque<short>>/2                       15.8 ns         15.8 ns
bm_find<std::deque<short>>/3                       20.5 ns         20.3 ns
bm_find<std::deque<short>>/4                       21.0 ns         21.0 ns
bm_find<std::deque<short>>/5                       23.0 ns         22.1 ns
bm_find<std::deque<short>>/6                       22.6 ns         23.0 ns
bm_find<std::deque<short>>/7                       23.4 ns         23.7 ns
bm_find<std::deque<short>>/8                       24.4 ns         24.9 ns
bm_find<std::deque<short>>/16                      26.6 ns         27.2 ns
bm_find<std::deque<short>>/64                      43.2 ns         40.9 ns
bm_find<std::deque<short>>/512                      124 ns         90.7 ns
bm_find<std::deque<short>>/4096                     845 ns          525 ns
bm_find<std::deque<short>>/32768                   7273 ns         3194 ns
bm_find<std::deque<short>>/262144                 53710 ns        24385 ns
bm_find<std::deque<short>>/1048576               216086 ns        96195 ns
bm_find<std::deque<int>>/1                         6.03 ns         10.3 ns
bm_find<std::deque<int>>/2                         15.6 ns         10.3 ns
bm_find<std::deque<int>>/3                         19.1 ns         10.3 ns
bm_find<std::deque<int>>/4                         22.3 ns         10.3 ns
bm_find<std::deque<int>>/5                         23.5 ns         10.4 ns
bm_find<std::deque<int>>/6                         23.1 ns         10.3 ns
bm_find<std::deque<int>>/7                         23.7 ns         10.2 ns
bm_find<std::deque<int>>/8                         24.5 ns         10.2 ns
bm_find<std::deque<int>>/16                        27.9 ns         26.6 ns
bm_find<std::deque<int>>/64                        42.6 ns         32.2 ns
bm_find<std::deque<int>>/512                        123 ns         43.0 ns
bm_find<std::deque<int>>/4096                       874 ns         93.5 ns
bm_find<std::deque<int>>/32768                     7031 ns          751 ns
bm_find<std::deque<int>>/262144                   57723 ns         6169 ns
bm_find<std::deque<int>>/1048576                 230867 ns        35851 ns
bm_ranges_find<std::deque<char>>/1                 5.97 ns         10.6 ns
bm_ranges_find<std::deque<char>>/2                 16.0 ns         10.5 ns
bm_ranges_find<std::deque<char>>/3                 19.5 ns         10.5 ns
bm_ranges_find<std::deque<char>>/4                 21.1 ns         10.6 ns
bm_ranges_find<std::deque<char>>/5                 22.8 ns         10.5 ns
bm_ranges_find<std::deque<char>>/6                 22.8 ns         10.6 ns
bm_ranges_find<std::deque<char>>/7                 23.4 ns         10.8 ns
bm_ranges_find<std::deque<char>>/8                 24.1 ns         10.5 ns
bm_ranges_find<std::deque<char>>/16                26.9 ns         10.6 ns
bm_ranges_find<std::deque<char>>/64                50.2 ns         27.2 ns
bm_ranges_find<std::deque<char>>/512                126 ns         38.3 ns
bm_ranges_find<std::deque<char>>/4096               868 ns         53.8 ns
bm_ranges_find<std::deque<char>>/32768             6695 ns          161 ns
bm_ranges_find<std::deque<char>>/262144           54411 ns         1497 ns
bm_ranges_find<std::deque<char>>/1048576         241699 ns         6042 ns
bm_ranges_find<std::deque<short>>/1                6.39 ns         6.31 ns
bm_ranges_find<std::deque<short>>/2                15.8 ns         15.9 ns
bm_ranges_find<std::deque<short>>/3                19.0 ns         19.8 ns
bm_ranges_find<std::deque<short>>/4                20.8 ns         20.9 ns
bm_ranges_find<std::deque<short>>/5                21.8 ns         22.1 ns
bm_ranges_find<std::deque<short>>/6                23.0 ns         23.0 ns
bm_ranges_find<std::deque<short>>/7                23.2 ns         23.9 ns
bm_ranges_find<std::deque<short>>/8                23.7 ns         24.4 ns
bm_ranges_find<std::deque<short>>/16               26.6 ns         26.8 ns
bm_ranges_find<std::deque<short>>/64               43.4 ns         39.7 ns
bm_ranges_find<std::deque<short>>/512               131 ns         90.5 ns
bm_ranges_find<std::deque<short>>/4096              851 ns          523 ns
bm_ranges_find<std::deque<short>>/32768            7370 ns         3166 ns
bm_ranges_find<std::deque<short>>/262144          60778 ns        24814 ns
bm_ranges_find<std::deque<short>>/1048576        229288 ns        99273 ns
bm_ranges_find<std::deque<int>>/1                  6.43 ns         10.2 ns
bm_ranges_find<std::deque<int>>/2                  16.6 ns         10.2 ns
bm_ranges_find<std::deque<int>>/3                  19.6 ns         10.2 ns
bm_ranges_find<std::deque<int>>/4                  21.0 ns         10.2 ns
bm_ranges_find<std::deque<int>>/5                  21.9 ns         10.4 ns
bm_ranges_find<std::deque<int>>/6                  22.7 ns         10.2 ns
bm_ranges_find<std::deque<int>>/7                  23.9 ns         10.2 ns
bm_ranges_find<std::deque<int>>/8                  23.8 ns         10.2 ns
bm_ranges_find<std::deque<int>>/16                 27.2 ns         27.1 ns
bm_ranges_find<std::deque<int>>/64                 42.4 ns         32.4 ns
bm_ranges_find<std::deque<int>>/512                 122 ns         43.0 ns
bm_ranges_find<std::deque<int>>/4096                895 ns         93.7 ns
bm_ranges_find<std::deque<int>>/32768              6890 ns          756 ns
bm_ranges_find<std::deque<int>>/262144            54025 ns         6102 ns
bm_ranges_find<std::deque<int>>/1048576          221558 ns        32783 ns
```
2023-12-15 17:10:16 +01:00
Louis Dionne
f0d4811690
[libc++] Add CI job for testing macOS C++03 (#75355)
It's not that I have much love for C++03, but we should ensure that it
works. Some recent changes broke this configuration because slightly
older Clang versions don't support attribute syntax in C++03 mode.
2023-12-13 18:05:36 -05:00
Jakub Mazurkiewicz
0b46606ca5
[libc++] Fix take_view::__sentinel's operator== (#74655)
* Fix `take_view::__sentinel`'s `operator==`
* Rename `ranges/range.adaptors/range.take/sentinel/base.pass.cpp`
directory to
`ranges/range.adaptors/range.take/range.take.sentinel/base.pass.cpp`
* Add ***full*** test coverage for `take_view::__sentinel`'s
`operator==`
* Drive-by: fix comment in `base.pass.cpp` test
* Close #55211
2023-12-13 19:00:37 +00:00
Louis Dionne
b81c69415e
[libc++][NFC] Add a few explicit 'inline' keywords, mostly in <chrono> (#75234)
Even though constexpr implicitly makes functions inline, we try not to
rely on this implicit effect in the code base. We are mostly consistent
about using `inline` on non-template free-functions to make it clear
that we don't have an ODR violation.

This patch simply fixes a few places where we didn't explicitly use
inline on non-template free functions, presumably because they were
constexpr.

Fixes #75227
2023-12-13 10:17:27 -05:00
Stephan T. Lavavej
869133771a
[libc++] views::split and views::lazy_split shouldn't be range adaptor closures (#75266)
Fixes #75002. Found while running libc++'s tests with MSVC's STL.

This is a superset of #74961 that also fixes the product code
and adds a regression test. Thanks again, @cpplearner!

To summarize: `views::split` and `views::lazy_split` aren't unary,
aren't range adaptor **closure** objects, and can't be piped. However,
\[range.adaptor.object\]/8 says that `views::split(pattern)` and
`views::lazy_split(pattern)` produce unary, pipeable, range adaptor
closure objects.

This PR adjusts the test coverage accordingly, allowing it to portably
pass for libc++ and MSVC's STL.
2023-12-13 02:37:05 -08:00
Tacet
9ed20568e7
[ASan][libc++] std::basic_string annotations (#72677)
This commit introduces basic annotations for `std::basic_string`,
mirroring the approach used in `std::vector` and `std::deque`.
Initially, only long strings with the default allocator will be
annotated. Short strings (_SSO - short string optimization_) and strings
with non-default allocators will be annotated in the near future, with
separate commits dedicated to enabling them. The process will be similar
to the workflow employed for enabling annotations in `std::deque`.

**Please note**: these annotations function effectively only when libc++
and libc++abi dylibs are instrumented (with ASan). This aligns with the
prevailing behavior of Memory Sanitizer.

To avoid breaking everything, this commit also appends
`_LIBCPP_INSTRUMENTED_WITH_ASAN` to `__config_site` whenever libc++ is
compiled with ASan. If this macro is not defined, string annotations are
not enabled. However, linking a binary that does **not** annotate
strings with a dynamic library that annotates strings, is not permitted.

Originally proposed here: https://reviews.llvm.org/D132769

Related patches on Phabricator:
- Turning on annotations for short strings:
https://reviews.llvm.org/D147680
- Turning on annotations for all allocators:
https://reviews.llvm.org/D146214

This PR is a part of a series of patches extending AddressSanitizer C++
container overflow detection capabilities by adding annotations, similar
to those existing in `std::vector` and `std::deque` collections. These
enhancements empower ASan to effectively detect instances where the
instrumented program attempts to access memory within a collection's
internal allocation that remains unused. This includes cases where
access occurs before or after the stored elements in `std::deque`, or
between the `std::basic_string`'s size (including the null terminator)
and capacity bounds.

The introduction of these annotations was spurred by a real-world
software bug discovered by Trail of Bits, involving an out-of-bounds
memory access during the comparison of two strings using the
`std::equals` function. This function was taking iterators
(`iter1_begin`, `iter1_end`, `iter2_begin`) to perform the comparison,
using a custom comparison function. When the `iter1` object exceeded the
length of `iter2`, an out-of-bounds read could occur on the `iter2`
object. Container sanitization, upon enabling these annotations, would
effectively identify and flag this potential vulnerability.

This Pull Request introduces basic annotations for `std::basic_string`.
Long strings exhibit structural similarities to `std::vector` and will
be annotated accordingly. Short strings are already implemented, but
will be turned on separately in a forthcoming commit. Look at [a
comment](https://github.com/llvm/llvm-project/pull/72677#issuecomment-1850554465)
below to read about SSO issues at current moment.

Due to the functionality introduced in
[D132522](dd1b7b797a),
the `__sanitizer_annotate_contiguous_container` function now offers
compatibility with all allocators. However, enabling this support will
be done in a subsequent commit. For the time being, only strings with
the default allocator will be annotated.

If you have any questions, please email:
- advenam.tacet@trailofbits.com
- disconnect3d@trailofbits.com
2023-12-13 06:05:34 +01:00
Mark de Wever
766bf140ff
[libc++][chrono] Fixes year_month year wrapping. (#74938)
Adding months to a year_month should wrap the year when the month
becomes greater than twelve or less than one.

This fixes the issue for year_month. Other classes with a year and month
do not have this issue. This has been verified and tests are added to
avoid possible regressions.

Also fixes some variable copy-paste errors in the tests.

Fixes https://github.com/llvm/llvm-project/issues/73162
2023-12-12 19:14:13 +01:00
Jakub Mazurkiewicz
6a66467499
[libc++] P2770R0: Stashing stashing iterators for proper flattening (#66033)
- Partially implements P2770R0 (http://wg21.link/p2770)
- Fixes https://wg21.link/LWG3698, https://wg21.link/LWG3700, and https://wg21.link/LWG3791
- join_with_view hasn't been done yet since this type isn't implemented yet
- Rename tuple test directory to match the standard (which changed in P2770R0)
- Rename join_view test directory to match the standard
2023-12-12 09:45:14 -05:00
Louis Dionne
10582cbf2e [libc++] Fix incorrectly-placed attribute 2023-12-12 09:32:35 -05:00
Stephan T. Lavavej
67c4033358
[libc++] LWG-4021 "mdspan::is_always_meow() should be noexcept", use LIBCPP_STATIC_ASSERT for noexcept strengthening (#74254)
Found while running libc++'s test suite with MSVC's STL.

* I've filed [LWG-4021](https://cplusplus.github.io/LWG/issue4021)
"`mdspan::is_always_meow()` should be `noexcept`" and implemented this
in libc++'s product and test code.
* Use `LIBCPP_STATIC_ASSERT` to avoid issues with `noexcept`
strengthening in MSVC's STL.
+ As permitted by the Standard, MSVC's STL conditionally strengthens
`mdspan` construction/`is_meow`/`stride` and `elements_view` iterator
`base() &&`, and always strengthens `basic_stringbuf` `swap`.
+ In `mdspan/properties.pass.cpp`, this also upgrades runtime `assert`s
to `static_assert`s.
* Improvement: Upgrade `assert` to `static_assert` when inspecting the
`noexcept`ness of `std::ranges::iter_move`. (These `!noexcept` tests
weren't causing issues for MSVC's STL, so I didn't change them to be
libc++-specific.)
2023-12-10 11:52:14 +01:00
Mark de Wever
b5a6e8a433 [NFC][libc++] Rewrites a return statement.
This fixes a clang-tidy diagnostic when building libc++ with RTTI
disabled. This was originally part of #65518.
2023-12-09 15:50:18 +01:00
Mark de Wever
e3f154d873
[libc++] Implements Runtime format strings. (#73353)
This change requires quite a number of changes in the tests; this is not
code I expect people to use in the wild. So I don't expect breakage for
users.

Implements:
- P2905R2 Runtime format strings, as a Defect Report
2023-12-09 12:32:17 +01:00
W-50243
6ea334456d
[libc++] Fix regex_traits::isctype on big endian platforms (#73200)
'isctype' fails in arm64-big-endian because the __regex_word involved
in mask operation is not changed based on the platform endianness, while
the character mask does change.
2023-12-07 09:18:00 -05:00
Nhat Nguyen
727fef79c0
[libc++] Add floating point type check for uniform real distribution (#70564)
Fixes #62433

Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
2023-12-07 09:06:54 -05:00
Stephan T. Lavavej
3aee4a9628
[libc++] Update <source_location> and msvc_stdlib_force_include.h (#74266)
This makes libc++'s <filesystem> tests compatible with MSVC's STL.

In msvc_stdlib_force_include.h, we need to define 3 more macros:

- _CRT_DECLARE_NONSTDC_NAMES activates the POSIX names of
  `getcwd` etc. As the comment explains, we need this because
  we test with Clang `-fno-ms-compatibility`, which defines 
  `__STDC__` to `1`, which causes the UCRT headers to disable 
  the POSIX names by default.
- Then we need _CRT_NONSTDC_NO_WARNINGS to avoid emitting
  deprecation warnings about the POSIX names.
- Finally, we need `NOMINMAX` to seal away the ancient evil.

These macros are documented in https://learn.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=msvc-170.

As a drive-by change, the patch adds a "simulated" macro for 
__has_feature(hwaddress_sanitizer). It also clang-formats all
of msvc_stdlib_force_include.h and removes guards for
__has_builtin(__builtin_source_location) in <source_location>,
since those are not needed anymore.
2023-12-06 09:04:06 -05:00
Stephan T. Lavavej
bfdc562d0c
[libc++] Fix copy-paste damage in ranges::rotate_copy and its test (#74544)
Found while running libc++'s tests with MSVC's STL.

`ranges::rotate_copy` takes `forward_iterator`s as this test's comment
banner correctly depicts. However, this test had bogus assertions
expecting that `ranges::rotate_copy` would be constrained away for
not-quite-**bidi** iterators. @philnik777 confirmed that these were
copy-paste relics from the `ranges::reverse_copy` test.

I fixed this by replacing the assertions with the test types that aren't
quite **forward** iterators/ranges. Additionally, I noticed that the
top-level `test()` function was missing coverage with the weakest
possible `forward_iterator<int*>`.

This revealed that the product code in `ranges_rotate_copy.h` was
similarly damaged. In addition to fixing it by taking `forward_iterator`
and `forward_range` as depicted in the Standard, this drops the
inclusion of `<__iterator/reverse_iterator.h>` as this algorithm doesn't
need `std::__reverse_range`.
2023-12-06 02:29:09 -08:00
Tacet
02f4b36ad5
[libc++] Refactor of ASan annotation functions (#74023)
This commit refactors the ASan annotation functions in libc++ to reduce
unnecessary code duplication. Additionally it adds a small optimization.

- Eliminates two redundant function versions by utilizing the
`[[maybe_unused]]` attribute and guarding function bodies with `#ifndef
_LIBCPP_HAS_NO_ASAN`.
- Introduces an additional guard to an auxiliary function, allowing the
removal of a no-ops function body. This approach avoids relying on the
optimizer for code elimination.

Fixes #73043
2023-12-05 13:27:08 -05:00
Louis Dionne
953ac952eb
[libc++][NFC] Use aliases instead of typedefs in std::array (#74491)
As requested in https://github.com/llvm/llvm-project/pull/74482.
2023-12-05 11:21:06 -05:00
Louis Dionne
77a00c0d54
[libc++] Replace uses of _VSTD:: by std:: (#74331)
As part of the upcoming clang-formatting of libc++, this patch performs
the long desired removal of the _VSTD macro.

See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.
2023-12-05 11:19:15 -05:00
Louis Dionne
b18a46e35d
[libc++][NFC] Add a few clang-format annotations (#74352)
This is in preparation for clang-formatting the whole code base. These
annotations are required either to avoid clang-format bugs or because
the manually formatted code is significantly more readable than the
clang-formatted alternative. All in all, it seems like very few
annotations are required, which means that clang-format is doing a very
good job in most cases.
2023-12-04 15:17:31 -05:00
Louis Dionne
4c19854222
[libc++] Rename _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI (#74095)
In preparation for running clang-format on the whole code base, we are
also removing mentions of the legacy _LIBCPP_INLINE_VISIBILITY macro in
favor of the newer _LIBCPP_HIDE_FROM_ABI.

We're still leaving the definition of _LIBCPP_INLINE_VISIBILITY to avoid
creating needless breakage in case some older patches are checked-in
with mentions of the old macro. After we branch for LLVM 18, we can do
another pass to clean up remaining uses of the macro that might have
gotten introduced by mistake (if any) and remove the macro itself at the
same time. This is just a minor convenience to smooth out the transition
as much as possible.

See
https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all
for the clang-format proposal.
2023-12-04 10:25:14 -05:00
Dominik Wójt
4c338f80c4
[libc++] picolibc: avoid warning in __locale (#73937) 2023-11-30 09:32:06 -05:00
Mark de Wever
efc60dc007
[libc++] Reenable codecvt in the dylib. (#73679)
The header is used in the dylib, this is not an issue at the moment
since the dylib is built using C++23 but it would be when building
with C++26.

Post release comments in #72496 seem to indicate this removal is an
issue for Fuchsia.
2023-11-29 18:02:10 -05:00
Mark de Wever
16b8c9608f
[libc++][format] Fixes formatting code units as integers. (#73396)
This paper was voted in as a DR, so it's retroactively enabled back to
C++20; the C++ version that introduced std::format.

Implements:
- P2909R4 Fix formatting of code units as integers (Dude, where’s my
``char``?)
2023-11-29 17:55:09 +01:00
Louis Dionne
1a5af34e6f
[libc++] Speed up classic locale (take 2) (#73533)
Locale objects use atomic reference counting, which may be very
expensive in parallel applications. The classic locale is used by
default by all streams and can be very contended. But it's never
destroyed, so the reference counting is also completely pointless on the
classic locale. Currently ~70% of time in the parallel stringstream
benchmarks is spent in locale ctor/dtor. And the execution radically
slows down with more threads.

Avoid reference counting on the classic locale. With this change
parallel benchmarks start to scale with threads.

This is a re-application of f8afc53d64 (aka PR #72112) which was
reverted in 4e0c48b907 because it broke the sanitizer builds due
to an initialization order fiasco. This issue has now been fixed by
ensuring that the locale is constinit'ed.

Co-authored-by: Dmitry Vyukov <dvyukov@google.com>
2023-11-29 09:31:05 -05:00
Louis Dionne
ac8c9f1e39
[libc++] Properly guard std::filesystem with >= C++17 (#72701)
<filesystem> is a C++17 addition. In C++11 and C++14 modes, we actually
have all the code for <filesystem> but it is hidden behind a non-inline
namespace __fs so it is not accessible. Instead of doing this unusual
dance, just guard the code for filesystem behind a classic C++17 check
like we normally do.
2023-11-28 18:41:59 -05:00
Nikolas Klauser
ed27a4edb0
[libc++][PSTL] Implement std::equal (#72448)
Differential Revision: https://reviews.llvm.org/D157131

Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
2023-11-28 16:02:18 -05:00
James Y Knight
e1f59ad9f6
Mark some std::string functions noinline. (#72869)
The intent of these particular functions, since their introduction, was
to NOT be inlinable.

However, the mechanism by which this was accomplished was non-obvious,
and stopped working when string is compiled for C++20.

A longstanding behavior specified by the C++ standard is that
instantiation of the body of a template function is suppressed by an
extern template declaration -- unless the function is explicitly marked
either constexpr or inline. Of course, if the body is not instantiated,
then it cannot possibly be inlined, and thus all the functions listed in
libcxx/include/__string/extern_template_lists.h were uninlineable.

But, in C++20 mode, string functions were annotated constexpr, which
means they _are_ instantiated, and do become inlineable. And, in fact,
they do get inlined, which has caused noticeable binary-size growth for
users.

For example, in C++17,
`std::string f(std::string *in) { return *in; }`
does not inline the copy-constructor call, and instead generates a call
to the exported function defined in the libc++ shared library.

I think we probably don't want to mark all functions that are currently
in the extern template list as noinline, as many of them really are
reasonable inlining candidates. Thus, I've restricted this change to
only the few functions that were clearly intended to be outlined.

See commits like b019c5c037 (and some
others like it) for background, in which functions were removed from the
extern template list in the unstable ABI in order to allow the
short-string case to be inlined, while moving the long-string case to a
separate function, added to the extern template list.
2023-11-28 15:57:00 -05:00
Kirill Stoimenov
4e0c48b907 Revert "[libc++] Speed up classic locale (#72112)"
Looks like it broke the ASAN build: https://lab.llvm.org/buildbot/#/builders/168/builds/17053/steps/9/logs/stdio

This reverts commit f8afc53d64.
2023-11-27 20:21:58 +00:00
Louis Dionne
12bb2910c3
[libc++] Remove experimental pmr headers now shipped in mainline (#73172)
Several experimental headers around std::pmr have been slated for
removal for a while now. This patch actually performs the removal and
cleanups from the code base.
2023-11-27 10:54:35 -05:00
Louis Dionne
936180a5e8 [libc++][NFC] Fix typo in comment 2023-11-27 10:35:07 -05:00
Dmitry Vyukov
f8afc53d64
[libc++] Speed up classic locale (#72112)
Locale objects use atomic reference counting, which may be very
expensive in parallel applications. The classic locale is used by
default by all streams and can be very contended. But it's never
destroyed, so the reference counting is also completely pointless on the
classic locale. Currently ~70% of time in the parallel stringstream
benchmarks is spent in locale ctor/dtor. And the execution radically
slows down with more threads.

Avoid reference counting on the classic locale. With this change
parallel benchmarks start to scale with threads.

Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

```
                              │   baseline   │    optimized                            │
                              │    sec/op    │    sec/op      vs base                  │
Istream_numbers/0/threads:1      4.672µ ± 0%   4.419µ ± 0%     -5.42% (p=0.000 n=30+39)
Istream_numbers/0/threads:72   539.817µ ± 0%   9.842µ ± 1%    -98.18% (p=0.000 n=30+40)
Istream_numbers/1/threads:1      4.890µ ± 0%   4.750µ ± 0%     -2.85% (p=0.000 n=30+40)
Istream_numbers/1/threads:72     66.44µ ± 1%   10.14µ ± 1%    -84.74% (p=0.000 n=30+40)
Istream_numbers/2/threads:1      4.888µ ± 0%   4.746µ ± 0%     -2.92% (p=0.000 n=30+40)
Istream_numbers/2/threads:72     494.8µ ± 0%   410.2µ ± 1%    -17.11% (p=0.000 n=30+40)
Istream_numbers/3/threads:1      4.697µ ± 0%   4.695µ ± 5%          ~ (p=0.391 n=30+37)
Istream_numbers/3/threads:72     421.5µ ± 7%   421.9µ ± 9%          ~ (p=0.665 n=30)
Ostream_number/0/threads:1       183.0n ± 0%   141.0n ± 2%    -22.95% (p=0.000 n=30)
Ostream_number/0/threads:72    24196.5n ± 1%   343.5n ± 3%    -98.58% (p=0.000 n=30)
Ostream_number/1/threads:1       250.0n ± 0%   196.0n ± 2%    -21.60% (p=0.000 n=30)
Ostream_number/1/threads:72    16260.5n ± 0%   407.0n ± 2%    -97.50% (p=0.000 n=30)
Ostream_number/2/threads:1       254.0n ± 0%   196.0n ± 1%    -22.83% (p=0.000 n=30)
Ostream_number/2/threads:72      28.49µ ± 1%   18.89µ ± 5%    -33.72% (p=0.000 n=30)
Ostream_number/3/threads:1       185.0n ± 0%   185.0n ± 0%      0.00% (p=0.017 n=30)
Ostream_number/3/threads:72      19.38µ ± 4%   19.33µ ± 5%          ~ (p=0.425 n=30)
```
2023-11-27 07:00:21 +01:00
philnik777
1314e8774f
[libc++] Add missing headers to the modulemap (#71127)
I don't know when, but at some point we lost test coverage to ensue that
all the headers are in the modulemap. This adds a test to make sure all
the headers (excluding a few which shouldn't be part of the modulemap)
are at least mentioned. This also fixes a few headers which bit-rotted
while we were missing the coverage.
2023-11-27 00:14:59 +01:00
philnik777
cd9829c231
[libc++][NFC] Use __construct_at and __destroy_at instead of using preprocessor conditionals (#70866) 2023-11-26 20:47:03 +01:00