Commit Graph

7 Commits

Author SHA1 Message Date
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
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
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
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 4cd6ca102a [libc++] NFC: Normalize `#endif //` comment indentation 2021-04-20 12:03:32 -04:00
Louis Dionne 0b439e4cc9 [libc++] Split std::allocator out of <memory>
Differential Revision: https://reviews.llvm.org/D100216
2021-04-12 11:46:29 -04:00