After rebasing my trivially-relocatable branch, this behavior was broken... but no libc++ unit test caught it! Add a regression test specifically for erasing out of a vector.
I'll do some more investigation of the actual root cause of the trivially-relocatable bug that this is a regression test for, since I have to fix it anyway. Still, I was shocked that libc++'s test suite didn't catch a simple misbehavior. (The specific misbehavior in my case was that after erasing l1.begin() you'd get {2,2,3,4} instead of {2,3,4,5} — it's shifting down only one element instead of all of them. But I haven't yet looked at my code to see why that is.)
EDIT: I have now looked at my trivially-relocatable bug. The problem was a missing * sizeof(_Tp) in the third argument to memmove here:
pointer __p = this->__begin_ + __ps;
- this->__destruct_at_end(_VSTD::move(__p + 1, this->__end_, __p));
+ _Tp *__rawp = _VSTD::__to_address(__p);
+ if (__vector_relocate_via_memcpy<_Tp, _Allocator>::value) {
+ __alloc_traits::destroy(this->__alloc(), __rawp);
+ --this->__end_;
+ if (__p != this->__end_) {
+ _VSTD::memmove(__rawp, __rawp + 1, this->__end_ - __p);
+ }
+ } else {
+ this->__destruct_at_end(_VSTD::move(__p + 1, this->__end_, __p));
+ }
this->__invalidate_iterators_past(__p-1);I still claim that it's useful to have a regression test for this bug, even though the bug itself was only local to my checkout. :)