Commit Graph

79 Commits

Author SHA1 Message Date
Arthur O'Dwyer 2eb2ff2a02 [libc++] Merge _LIBCPP_HAS_NO_RANGES into _LIBCPP_HAS_NO_CONCEPTS. NFC.
The macro that opts out of `std::ranges::` functionality is called
`_LIBCPP_HAS_NO_INCOMPLETE_RANGES`, and is unrelated to this macro
which is specifically about _compiler_ support for the _syntax_.

The only non-mechanical diff here is in `<__config>`.

Differential Revision: https://reviews.llvm.org/D118507
2022-01-31 12:10:22 -05:00
Arthur O'Dwyer 63a991d035 [libc++] Eliminate the `__function_like` helper.
As prefigured in the comments on D115315.
This gives us one unified style for all niebloids,
and also simplifies the modulemap.

Differential Revision: https://reviews.llvm.org/D116570
2022-01-20 14:40:16 -05:00
Arthur O'Dwyer cba72e4ce2 [libc++] Normalize some whitespace in preparation for D116570. NFC. 2022-01-15 12:20:33 -05:00
Konstantin Varlamov b9bc3c107c [libc++][ranges] Implement `construct_at` and `destroy{,_at}`.
Differential Revision: https://reviews.llvm.org/D116078
2022-01-12 16:01:04 -08:00
Konstantin Varlamov 8d23b7420c [libc++][ranges] Implement `uninitialized_copy{,_n}` and `uninitialized_move{,_n}`.
Also implement `in_out_result` which is a prerequisite.

Differential Revision: https://reviews.llvm.org/D116023
2022-01-10 22:49:50 -08:00
Arthur O'Dwyer 4d81a46f7f [libc++] Alphabetize header #includes. NFCI.
The NFC part of D116809. We still want to enforce this in CI,
but the mechanism for that is still to-be-determined.

Differential Revision: https://reviews.llvm.org/D116809
2022-01-10 16:30:38 -05:00
Nico Weber 085f078307 Revert "Revert D109159 "[amdgpu] Enable selection of `s_cselect_b64`.""
This reverts commit 859ebca744.
The change contained many unrelated changes and e.g. restored
unit test failes for the old lld port.
2022-01-05 13:10:25 -05:00
David Salinas 859ebca744 Revert D109159 "[amdgpu] Enable selection of `s_cselect_b64`."
This reverts commit 640beb38e7.

That commit caused performance degradtion in Quicksilver test QS:sGPU and a functional test failure in (rocPRIM rocprim.device_segmented_radix_sort).
Reverting until we have a better solution to s_cselect_b64 codegen cleanup

Change-Id: Ibf8e397df94001f248fba609f072088a46abae08

Reviewed By: kzhuravl

Differential Revision: https://reviews.llvm.org/D115960

Change-Id: Id169459ce4dfffa857d5645a0af50b0063ce1105
2022-01-05 17:57:32 +00:00
Konstantin Varlamov 754ea6fd4d [libc++][ranges] Implement `uninitialized_value_construct{,_n}` and `uninitialized_fill{,_n}`.
Also:
- refactor out `__voidify`;
- use the `destroy` algorithm internally;
- refactor out helper classes used in tests for `uninitialized_*`
  algorithms.

Differential Revision: https://reviews.llvm.org/D115626
2021-12-20 00:24:27 -08:00
Konstantin Varlamov 3f630cff65 [libc++][ranges] Implement ranges::uninitialized_default_construct{,_n}.
Defined in [`specialized.algorithms`](wg21.link/specialized.algorithms).

Also:
- refactor the existing non-range implementation so that most of it
  can be shared between the range-based and non-range-based algorithms;
- remove an existing test for the non-range version of
  `uninitialized_default_construct{,_n}` that likely triggered undefined
  behavior (it read the values of built-ins after default-initializing
  them, essentially reading uninitialized memory).

Reviewed By: #libc, Quuxplusone, ldionne

Differential Revision: https://reviews.llvm.org/D115315
2021-12-14 14:11:46 -08:00
Nikolas Klauser a376a3f354 [libc++] Make __compressed_pair fully constexpr
Make `__compressed_pair` fully constexpr

Reviewed By: ldionne, #libc, nilayvaish

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D115687
2021-12-14 15:39:46 +01:00
Nikolas Klauser 4955095fe6 [libc++] Remove _LIBCPP_DEFAULT
clang has `= default` as an extension in c++03, so just use it.

Reviewed By: ldionne, Quuxplusone, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D115275
2021-12-07 22:18:38 +01:00
Konstantin Varlamov 2d9efcfeec [libc++][ranges] Implement [special.mem.concepts].
Implement the exposition-only concepts specified in
`[special.mem.concepts]`. These are all thin wrappers over other
concepts.

Reviewed By: #libc, Quuxplusone, ldionne

Differential Revision: https://reviews.llvm.org/D114761
2021-12-02 17:58:04 -08:00
Konstantin Varlamov 7da4ee6f23 [libcxx][NFC] Make sequence containers slightly more SFINAE-friendly during CTAD.
Disable the constructors taking `(size_type, const value_type&,
allocator_type)` if `allocator_type` is not a valid allocator.
Otherwise, these constructors are considered when resolving e.g.
`(int*, int*, NotAnAllocator())`, leading to a hard error during
instantiation. A hard error makes the Standard's requirement to not
consider deduction guides of the form `(Iterator, Iterator,
BadAllocator)` during overload resolution essentially non-functional.

The previous approach was to SFINAE away `allocator_traits`. This patch
SFINAEs away the specific constructors instead, for consistency with
`basic_string` -- see [LWG3076](wg21.link/lwg3076) which describes
a very similar problem for strings (note, however, that unlike LWG3076,
no valid constructor call is affected by the bad instantiation).

Differential Revision: https://reviews.llvm.org/D114311
2021-12-01 11:56:51 -08:00
Johan Berg 68e2231f87 [libc++] Value-initialize unique_ptr's deleter_type
According to the C++ standard, the stored pointer and the stored deleter
should be value-initialized.

Differential Revision: https://reviews.llvm.org/D113612
2021-11-24 17:31:34 -05:00
Louis Dionne 92832e4889 [libc++] Enable <atomic> when threads are disabled
std::atomic is, for the most part, just a thin veneer on top of compiler
builtins. Hence, it should be available even when threads are not available
on the system, and in fact there has been requests for such support.

This patch:
- Moves __libcpp_thread_poll_with_backoff to its own header so it can
  be used in <atomic> when threads are disabled.
- Adds a dummy backoff policy for atomic polling that doesn't know about
  threads.
- Adjusts the <atomic> feature-test macros so they are provided even when
  threads are disabled.
- Runs the <atomic> tests when threads are disabled.

rdar://77873569

Differential Revision: https://reviews.llvm.org/D114109
2021-11-17 23:02:58 -05:00
Nikolas Klauser b57c22ade8 [libc++] Implement P2186R2 (Remove Garbage Collection)
Reviewed By: Quuxplusone, #libc, ldionne

Differential Revision: https://reviews.llvm.org/D112869
2021-11-11 19:03:00 +01:00
Konstantin Varlamov 68072a7166 [libc++] P0433R2: test that deduction guides are properly SFINAEd away.
Deduction guides for containers should not participate in overload
resolution when called with certain incorrect types (e.g. when called
with a template argument in place of an `InputIterator` that doesn't
qualify as an input iterator). Similarly, class template argument
deduction should not select `unique_ptr` constructors that take a
a pointer.

The tests try out every possible incorrect parameter (but never more
than one incorrect parameter in the same invocation).

Also add deduction guides to the synopsis for associative and unordered
containers (this was accidentally omitted from [D112510](https://reviews.llvm.org/D112510)).

Differential Revision: https://reviews.llvm.org/D112904
2021-11-09 09:32:24 -08:00
Louis Dionne b2d25ef2d1 [libc++] Implement shared_ptr methods inline in the class
This patch refactors the shared_ptr methods from being defined out-of-line
to being defined inline in the class, like what we do for all new code in
the library. The benefits of doing that are that code is not as scattered
around and is hence easier to understand, and it avoids a ton of duplication
due to SFINAE checks. Defining the method where it is declared also removes
the possibility for mismatched attributes.

As a fly-by change, this also:

- Adds a few _LIBCPP_HIDE_FROM_ABI attributes
- Uses __enable_if_t instead of enable_if as a function argument, to match
  the style that we use everywhere else.

Differential Revision: https://reviews.llvm.org/D112478
2021-10-26 13:11:10 -04:00
Konstantin Varlamov 065ac30026 [libc++] LWG3001: add `remove_extent_t` to `weak_ptr::element_type`.
Also fix a few places in the `shared_ptr` implementation where
`element_type` was passed to the `__is_compatible` helper. This could
result in `remove_extent` being applied twice to the pointer's template
type (first by the definition of `element_type` and then by the helper),
potentially leading to somewhat less readable error messages for some
incorrect code.

Differential Revision: https://reviews.llvm.org/D112092
2021-10-25 11:15:54 -04:00
Mikhail Maltsev be10b1f1cc [libcxx] Make allocator<T>:allocate throw bad_array_new_length
Currently the member functions std::allocator<T>::allocate,
std::experimental::pmr::polymorphic_allocator::allocate and
std::resource_adaptor<T>::do_allocate throw an exception of type
std::length_error when the requested size exceeds the maximum size.

According to the C++ standard ([allocator.members]/4,
[mem.poly.allocator.mem]/1), std::allocator<T>::allocate and
std::pmr::polymorphic_allocator::allocate must throw a
std::bad_array_new_length exception in this case.

The patch fixes the issue with std::allocator<T>::allocate and changes
the type the exception thrown by
std::experimental::pmr::resource_adaptor<T>::do_allocate to
std::bad_array_new_length as well for consistency.

The patch resolves LWG 3237, LWG 3038 and LWG 3190.

Reviewed By: ldionne, #libc, Quuxplusone

Differential Revision: https://reviews.llvm.org/D110846
2021-10-18 19:12:42 +01:00
Louis Dionne 83bc88174e [libc++][NFC] Fix include guard for some detail header 2021-10-04 13:36:08 -04:00
Louis Dionne cb793e1a36 [libc++][NFCI] Remove uses of _LIBCPP_INLINE_VAR
All supported compilers provide support for inline variables in C++17 now.
Also, as a fly-by fix, replace some uses of _LIBCPP_CONSTEXPR by just
constexpr.

The only exception in this patch is `std::ignore`, which is provided
prior to C++17. Since it is defined in an anonymous namespace, it always
has internal linkage anyway, so using an inline variable there doesn't
provide any benefit. Instead, `inline` was removed entirely on `std::ignore`.

Differential Revision: https://reviews.llvm.org/D110243
2021-09-22 16:03:00 -04:00
Joe Loser 400b33e18d
[libc++] Disallow volatile types in std::allocator
LWG 2447 is marked as `Complete`, but there is no `static_assert` to
reject volatile types in `std::allocator`. See the discussion at
https://reviews.llvm.org/D108856.

Add `static_assert` in `std::allocator` to disallow volatile types. Since this
is an implementation choice, mark the binding test as `libc++` only.

Remove tests that use containers backed by `std::allocator` that test
the container when used with a volatile type.

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D109056
2021-09-22 11:47:38 -04:00
Louis Dionne b4e88d4db1 [libc++][NFC] Rename _EnableIf to __enable_if_t for consistency
In other places in the code, we use lowercase spelling for things that
are not available in prior standards.

Differential Revision: https://reviews.llvm.org/D109435
2021-09-08 15:20:58 -04:00
Arthur O'Dwyer 16bf43398a [libc++] Comma-operator-proof a lot of algorithm/container code.
Detected by evil-izing the widely used `MoveOnly` testing type.
I had to patch some tests that were themselves using its comma operator,
but I think that's a worthwhile cost in order to catch more places
in our headers that needed comma-proofing.

The trick here is that even `++ptr, SomeClass()` can find a comma operator
by ADL, if `ptr` is of type `Evil*`. (A comma between two operands
of non-class-or-enum type is always treated as the built-in
comma, without ADL. But if either operand is class-or-enum, then
ADL happens for _both_ operands' types.)

Differential Revision: https://reviews.llvm.org/D109414
2021-09-08 13:34:01 -04:00
Louis Dionne 4e0ea2cf2e [libc++] Use enable_if_t instead of _EnableIf
I just ran into a compiler error involving __bind_back and some overloads
that were being disabled with _EnableIf. I noticed that the error message
was quite bad and did not mention the reason for the overload being
excluded. Specifically, the error looked like this:

     candidate template ignored: substitution failure [with _Args =
     <ContiguousView>]: no member named '_EnableIfImpl' in 'std::_MetaBase<false>'

Instead, when using enable_if or enable_if_t, the compiler is clever and
can produce better diagnostics, like so:

     candidate template ignored: requirement 'is_invocable_v<
          std::__bind_back_op<1, std::integer_sequence<unsigned long, 0>>,
          std::ranges::views::__transform::__fn &, std::tuple<PlusOne> &,
          ContiguousView>' was not satisfied [with _Args = <ContiguousView>]

Basically, it tries to do a poor man's implementation of concepts, which
is already a lot better than simply complaining about substitution failure.

Hence, this commit uses enable_if_t instead of _EnableIf whenever
possible. That is both more straightforward than using the internal
helper, and also leads to better error messages in those cases.

I understand the motivation for _EnableIf's implementation was to improve
compile-time performance, however I believe striving to improve error
messages is even more important for our QOI, hence this patch. Furthermore,
it is unclear that _EnableIf actually improved compile-time performance
in any noticeable way (see discussion in the review for details).

Differential Revision: https://reviews.llvm.org/D108216
2021-09-08 09:09:28 -04:00
Arthur O'Dwyer dadbe88a13 [libc++] Fix std::to_address(array).
There were basically two bugs here:

When C++20 `to_address` is called on `int arr[10]`, then `const _Ptr&` becomes
a reference to a const array, and then we dispatch to `__to_address<const int(&)[10]>`,
which, oops, gives us a `const int*` result instead of an `int*` result.
Solution: We need to provide the two standard-specified overloads of
`std::to_address` in exactly the same way that we provide two overloads
of `__to_address`.

When `__to_address` is called on a pointer type, `__to_address(const _Ptr&)`
is disabled so we successfully avoid trying to instantiate pointer_traits of
that pointer type. But when it's called on an array type, it's not disabled
for array types, so we go ahead and instantiate pointer_traits<int[10]>,
which goes boom. Solution: We need to disable `__to_address(const _Ptr&)`
for both pointer and array types. Also disable it for function types,
so that they get the nice error message; and put a test on it.

Differential Revision: https://reviews.llvm.org/D109331
2021-09-07 13:56:25 -04:00
Louis Dionne 3557c7c122 [libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs
Clang used to support [[nodebug]] everywhere except on typedefs. Since
we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE
in favour of always using _LIBCPP_NODEBUG.

Differential Revision: https://reviews.llvm.org/D108996
2021-09-01 10:51:09 -04:00
Arthur O'Dwyer c5e7981aec [libc++] Add missing space in (__map_value_compare&__y) etc. NFCI. 2021-08-31 14:30:20 -04:00
Louis Dionne 64184b4af0 [libc++][NFC] Remove useless _LIBCPP_PUSH_MACROS
Only files that actually use min/max are required to do this dance.

Differential Revision: https://reviews.llvm.org/D108778
2021-08-27 12:41:55 -04:00
Louis Dionne 0166690401 [libc++] Remove workarounds for the lack of deduction guides in C++17
All supported compilers have supported deduction guides in C++17 for a
while, so this isn't necessary anymore.

Differential Revision: https://reviews.llvm.org/D108213
2021-08-18 08:57:25 -04:00
Louis Dionne 7c81024a06 [libc++] Remove workarounds for missing __builtin_addressof
All supported compilers implement __builtin_addressof. Even MSVC implements
addressof as a simple call to __builtin_addressof, so it would work if we
were to port libc++ to that compiler.

Differential Revision: https://reviews.llvm.org/D107905
2021-08-11 17:05:12 -04:00
Louis Dionne c99f5b2af1 [libc++] Handle arrays in std::destroy_at
Also, improve tests for std::destroy and std::destroy_n so that they
check for array support.

These changes are part of http://wg21.link/p0896 (the One Ranges proposal).

Differential Revision: https://reviews.llvm.org/D106916
2021-07-30 09:39:36 -04:00
Christopher Di Bella 050b064f15 [libcxx][functional][modular] splices <functional> into modular headers
Differential Revision: https://reviews.llvm.org/D104942
2021-07-01 14:01:49 -04:00
Christopher Di Bella 69d5a66621 [libcxx][modularisation] splits `<utility>` into self-contained headers
* moves `std::hash` and `std::unary_function` into `__functional`
* Everything else goes into `__utility/${NAME}.h`

Differential Revision: https://reviews.llvm.org/D104002
2021-06-25 00:29:01 +00:00
Christopher Di Bella 6adbc83ee9 [libcxx][modularisation] moves <utility> content out of <type_traits>
Moves:

* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
  `__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
  `__algorithm/${FUNCTION_NAME}`

Differential Revision: https://reviews.llvm.org/D103734
2021-06-24 17:57:29 +00:00
Arthur O'Dwyer 317e92a3e8 [libc++] Enable `explicit` conversion operators, even in C++03 mode.
C++03 didn't support `explicit` conversion operators;
but Clang's C++03 mode does, as an extension, so we can use it.
This lets us make the conversion explicit in `std::function` (even in '03),
and remove some silly metaprogramming in `std::basic_ios`.

Drive-by improvements to the tests for these operators, in addition
to making sure all these tests also run in `c++03` mode.

Differential Revision: https://reviews.llvm.org/D104682
2021-06-22 13:35:59 -04:00
Louis Dionne 134723edd5 [libcxx] Move all algorithms into their own headers
This is a fairly mechanical change, it just moves each algorithm into
its own header. This is intended to be a NFC.

This commit re-applies 7ed7d4ccb8, which was reverted in 692d7166f7
because the Modules build got broken. The modules build has now been
fixed, so we're re-committing this.

Differential Revision: https://reviews.llvm.org/D103583

Attribution note
----------------
I'm only committing this. This commit is a mix of D103583, D103330 and
D104171 authored by:

Co-authored-by: Christopher Di Bella <cjdb@google.com>
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
2021-06-19 07:49:06 -04:00
Louis Dionne 71e4d434dc [libc++] Make sure std::allocator<void> is always trivial
When we removed the allocator<void> specialization, the triviality of
std::allocator<void> changed because the primary template had a
non-trivial default constructor and the specialization didn't
(so std::allocator<void> went from trivial to non-trivial).

This commit fixes that oversight by giving a trivial constructor to
the primary template when instantiated on cv-void.

This was reported in https://llvm.org/PR50299.

Differential Revision: https://reviews.llvm.org/D104398
2021-06-17 16:11:50 -04:00
Louis Dionne 87784cc6fb [libc++] Undeprecate the std::allocator<void> specialization
While the std::allocator<void> specialization was deprecated by
https://wg21.link/p0174#2.2, the *use* of std::allocator<void> by users
was not. The intent was that std::allocator<void> could still be used
in C++17 and C++20, but starting with C++20 (with the removal of the
specialization), std::allocator<void> would use the primary template.
That intent was called out in wg21.link/p0619r4#3.9.

As a result of this patch, _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS
will also not control whether the explicit specialization is provided or
not. It shouldn't matter, since in C++20, one can simply use the primary
template.

Fixes http://llvm.org/PR50299

Differential Revision: https://reviews.llvm.org/D104323
2021-06-16 09:54:29 -04:00
Christopher Di Bella 332da1c283 [libcxx][iwyu] ensures we IWYU as prep for modules
This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.

Differential Revision: https://reviews.llvm.org/D104175
2021-06-15 19:43:25 +00:00
Arthur O'Dwyer dc066888bd [libc++] [P0619] Add _LIBCPP_ABI_NO_BINDER_BASES and remove binder typedefs in C++20.
Differential Revision: https://reviews.llvm.org/D103753
2021-06-15 15:05:44 -04:00
Petr Hosek 692d7166f7 Revert "[libcxx][gardening] Move all algorithms into their own headers."
This reverts commit 7ed7d4ccb8 as it
uncovered a Clang bug PR50592.
2021-06-07 17:15:20 -07:00
Petr Hosek d9633f229c Revert "[libcxx][module-map] creates submodules for private headers"
This reverts commit f1417eb9b1 as it
uncovered a Clang bug PR50592.
2021-06-07 17:10:05 -07:00
zoecarver 7ed7d4ccb8 [libcxx][gardening] Move all algorithms into their own headers.
This is a fairly mechanical change, it just moves each algorithm into its own header. This is a NFC.

Note: during this change, I burned down all the includes, so this follows "include only and exactly what you use."

Differential Revision: https://reviews.llvm.org/D103583
2021-06-04 09:37:12 -07:00
Christopher Di Bella f1417eb9b1 [libcxx][module-map] creates submodules for private headers
Most of our private headers need to be treated as submodules so that
Clang modules can export things correctly. Previous commits that split
monolithic headers into smaller chunks were unaware of this requirement,
and so this is being addressed in one fell swoop. Moving forward, most
new headers will need to have their own submodule (anything that's
conditionally included is exempt from this rule, which means `__support`
headers aren't made into submodules).

This hasn't been marked NFC, since I'm not 100% sure that's the case.

Differential Revision: https://reviews.llvm.org/D103551
2021-06-03 18:18:30 +00:00
Louis Dionne 41bdf64d3e [libc++] Update all the pre-defined iterator types for C++20
Make sure we provide the correct It::difference_type member and update
the tests and synopses to be accurate.

Supersedes D102657 and D103101 (thanks to the original authors).

Differential Revision: https://reviews.llvm.org/D103273
2021-05-31 11:59:40 -04:00
Louis Dionne 1055cb91b4 [libc++] Deprecate std::iterator and remove it as a base class
C++17 deprecated std::iterator and removed it as a base class for all
iterator adaptors. We implement that change, but we still provide a way
to inherit from std::iterator in the few cases where doing otherwise
would be an ABI break.

Supersedes D101729 and the std::iterator base parts of D103101 and D102657.

Differential Revision: https://reviews.llvm.org/D103171
2021-05-27 11:34:04 -04:00
Arthur O'Dwyer d42d9e10b6 [libc++] [P0619] Hide not1 and not2 under _LIBCPP_ENABLE_CXX20_REMOVED_NEGATORS.
This also provides some of the scaffolding needed by D102992 and D101729, and mops up after D101730 etc.

Differential Revision: https://reviews.llvm.org/D103055
2021-05-25 16:57:16 -04:00