[libcxx-commits] [PATCH] D118279: [libcxx][test] MaybePOCCAAllocator should meet the Cpp17Allocator requirements

Arthur O'Dwyer via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Wed Jan 26 14:05:21 PST 2022


Quuxplusone accepted this revision as: Quuxplusone.
Quuxplusone added a comment.

LGTM as long as the answers to all my questions are "no, what I have written here is correct." ;)



================
Comment at: libcxx/test/support/allocators.h:196-199
+    template <class U>
+    struct rebind {
+        typedef MaybePOCCAAllocator<U, POCCAValue> other;
+    };
----------------
Isn't there allocator_traits magic that does this for all templates automatically? or is that only in pointer_traits?


================
Comment at: libcxx/test/support/allocators.h:207
+    MaybePOCCAAllocator(const MaybePOCCAAllocator<U, POCCAValue>& that)
+        : id_(that.id()) {}
+
----------------
If CI is happy with this, then OK, but I suspect that whatever is happening with `copy_assigned_into_` is not well-thought-out and works only by accident, wherever it's being used/tested.


================
Comment at: libcxx/test/support/allocators.h:231-232
 
-    friend bool operator==(const MaybePOCCAAllocator& lhs, const MaybePOCCAAllocator& rhs)
+    template <class U>
+    friend bool operator==(const MaybePOCCAAllocator& lhs, const MaybePOCCAAllocator<U, POCCAValue>& rhs)
     {
----------------
I kneejerk want to leave this `operator==` alone and rely on the implicit converting ctor you just added... but would that make `allocT == allocU` ambiguous because the compiler doesn't know which operand to convert?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118279



More information about the libcxx-commits mailing list