[libcxx-commits] [PATCH] D147741: [libc++, std::vector] call the optimized version of __uninitialized_allocator_copy for trivial types

[Nikolas Klauser via Phabricator via libcxx-commits]

philnik added a comment.

In D147741#4391032 <https://reviews.llvm.org/D147741#4391032>, @ilya-biryukov wrote:

> We've noticed during our integrate that the following code (godbolt <https://gcc.godbolt.org/z/3doG8c784>) started producing a compiler error after this change:
>
>   #include <vector>
>   
>   struct Value {};
>   template <class Iter>
>   struct WrappedIter : Iter {
>       using pointer = Value*;
>       using reference = Value&;
>   
>       pointer operator-> () { return &v; }
>       reference operator* () { return v;  }
>   
>   private:
>     Value v;
>   };
>   
>   
>   using WI = WrappedIter<std::vector<int>::iterator>;
>   void foo(WI b, WI e) {
>       std::vector<Value> v(b, e);
>   }
>
> Concretely, the call to vector constructor eventually gets to `std::__to_address` via `__unwrap_iter` and results in a compiler error:
>
>   /opt/compiler-explorer/clang-trunk-20230602/bin/../include/c++/v1/__algorithm/unwrap_iter.h:46:32: error: no matching function for call to '__to_address'
>   ...
>   /opt/compiler-explorer/clang-trunk-20230602/bin/../include/c++/v1/__memory/pointer_traits.h:172:6: note: candidate template ignored: could not match '_Tp *' against 'WrappedIter<std::__wrap_iter<int *>>'
>     172 | _Tp* __to_address(_Tp* __p) _NOEXCEPT {
>         |      ^
>   /opt/compiler-explorer/clang-trunk-20230602/bin/../include/c++/v1/__memory/pointer_traits.h:204:1: note: candidate template ignored: requirement 'integral_constant<bool, false>::value' was not satisfied [with _Pointer = WrappedIter<std::__wrap_iter<int *>>]
>     204 | __to_address(const _Pointer& __p) _NOEXCEPT {
>         | ^
>
> The code itself is wrong as the wrapper (unintentionally) pretends to be a contiguous iterator, but fails to provide a proper `std::to_address` implementation (as the arrow function is not const).
> Nevertheless, I wanted to sanity check that folks feel this new compiler error is standard-compliant. @hiraditya what are your thoughts on this?

Yes, this is compliant, since you claim to be a `contiguous_iterator`, but don't provide the full interface. Your code would fail in the exact same way if you called `std::sort`, `std::copy`, or other algorithms that also unwrap the iterator.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147741/new/

https://reviews.llvm.org/D147741