[libcxx-commits] [PATCH] D151953: [libc++] Fix std::copy and std::move for ranges with potentially overlapping tail padding
Alexander Kornienko via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Tue Jul 4 17:02:35 PDT 2023
alexfh added inline comments.
================
Comment at: libcxx/include/__string/constexpr_c_functions.h:149
+ for (; __count > 0; --__count)
+ __dest[__count - 1] = __src[__count - 1];
+ } else {
----------------
ldionne wrote:
> alexfh wrote:
> > Some of our (and third-party) code started triggering an error related to this line after this commit. It turns out, std::vector<T>::erase() doesn't compile now, if T is move-only: https://gcc.godbolt.org/z/Txnc66M97
> >
> > Is this intended?
> Hmm, thanks for the heads up. `vector<T>::erase(...)` should only require that `T` is move assignable. In fact, it looks like this is being triggered in the `std::move` algorithm -- we probably don't have tests with move-only types in `std::move`, which is pretty embarrassing. @philnik it looks like we need to check additional constraints before calling `__constexpr_memmove`. Using `std::move(__src[__count - 1])` here wouldn't be an option since the semantics wouldn't match those of `memmove` IMO.
If this is not intended, I'd ask for a revert, since the impact of this is rather large.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D151953/new/
https://reviews.llvm.org/D151953
More information about the libcxx-commits
mailing list