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. :)