Commit Graph

9 Commits

Author SHA1 Message Date
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 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
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
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 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 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 ab3fcc5065 [libc++] s/_VSTD::declval/declval/g. NFCI. 2021-05-11 12:23:55 -04:00
Louis Dionne 4cd6ca102a [libc++] NFC: Normalize `#endif //` comment indentation 2021-04-20 12:03:32 -04:00
Louis Dionne f992cfba71 [libc++] Split up __memory/base.h into meaningful headers 2021-04-14 13:59:03 -04:00