| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210665 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210507 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately there's no way to elegantly do this with pre-canned
algorithms. Using a generating iterator doesn't work because you default
construct for each element, then move construct into the actual slot
(bad for copy but non-movable types, and a little unneeded overhead even
in the move-only case), so just write it out manually.
This solution isn't exception safe (if one of the element's ctors calls
we don't fall back, destroy the constructed elements, and throw on -
which std::uninitialized_fill does do) but SmallVector (and LLVM) isn't
exception safe anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210495 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
To test cases that involve actual repetition (> 1 elements), at least
one element before the insertion point, and some elements of the
original range that still fit in that range space after insertion.
Actually we need coverage for the inverse case too (where no elements
after the insertion point fit into the previously allocated space), but
this'll do for now, and I might end up rewriting bits of SmallVector to
avoid that special case anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210436 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
when inserting repeated elements.
Also split and improve tests a bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210433 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210432 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
| |
caught some bugs I haven't fixed yet.
Specifically this caused inserting an element from a SmallVector into
itself when such an insertion would cause a reallocation. We have code
to handle this for non-reallocating cases, but it's not robust against
reallocation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210430 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
(& because it makes it easier to test, this also improves
correctness/performance slightly by moving the last element in an insert
operation, rather than copying it)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210429 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
with the already-moved-from value
This would cause the last element in a range to be in a moved-from state
after an insert at a non-end position, losing that value entirely in the
process.
Side note: move_backward is subtle. It copies [A, B) to C-1 and down.
(the fact that it decrements both the second and third iterators before
the first movement is the subtle part... kind of surprising, anyway)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210426 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
| |
When we were moving from a larger vector to a smaller one but didn't
need to re-allocate, we would move-assign over uninitialized memory in
the target, then move-construct that same data again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207663 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r203374.
Ambiguities in assign... oh well. I'm just going to revert this and
probably not try to recommit it as it's not terribly important.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203375 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
| |
Move a common utility (assign(iter, iter)) into SmallVector (some of the
others could be moved there too, but this one seemed particularly
generic) and replace repetitions overrides with using directives.
And simplify SmallVector::assign(num, element) while I'm here rather
than thrashing these files (that cause everyone to rebuild) again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203374 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169250 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test more than a single instantiation of SmallVector.
Add testing for 0, 1, 2, and 4 element sized "small" buffers. These
appear to be essentially untested in the unit tests until now.
Fix several tests to be robust in the face of a '0' small buffer. As
a consequence of this size buffer, the growth patterns are actually
observable in the test -- yes this means that many tests never caused
a grow to occur before. For some tests I've merely added a reserve call
to normalize behavior. For others, the growth is actually interesting,
and so I captured the fact that growth would occur and adjusted the
assertions to not assume how rapidly growth occured.
Also update the specialization for a '0' small buffer length to have all
the same interface points as the normal small vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161001 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
It always returns the iterator for the first inserted element, or the passed in
iterator if the inserted range was empty. Flesh out the unit test more and fix
all the cases it uncovered so far.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158645 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
range into a SmallVector.
Patch by Johannes Schaub!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158643 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
| |
for POD-like types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155791 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135375 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
|
|
| |
vec.insert(vec.begin(), vec[3]);
The issue was that vec[3] returns a reference into the vector, which is invalidated when insert() memmove's the elements down to make space. The method needs to specifically detect and handle this case to correctly match std::vector's semantics.
Thanks to Howard Hinnant for clarifying the correct behavior, and explaining how std::vector solves this problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134554 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
until other LLVM projects using these are cleaned up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117200 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111539 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99633 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
aligned storage, the capacity may be more than what is explicitly
requested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98846 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
- These allow clients to make use of the extra elements in the vector which
have already been allocated, without requiring them to be value initialized.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79433 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75422 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69846 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62035 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62025 91177308-0d34-0410-b5e6-96231b3b80d8
|
