| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
code using it more readable.
Also add a copySign static function that works more like the standard
function by accepting the value and sign-carying value as arguments.
No interesting logic here, but tests added to cover the basic API
additions and make sure they do something plausible.
llvm-svn: 219453
|
|
|
|
| |
llvm-svn: 219250
|
|
|
|
| |
llvm-svn: 219240
|
|
|
|
|
|
| |
Addressing post commit review feedback from Justin Bogner.
llvm-svn: 218821
|
|
|
|
|
|
| |
r218732.
llvm-svn: 218783
|
|
|
|
| |
llvm-svn: 218750
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This can be used for in-place initialization of non-moveable types.
For compilers that don't support variadic templates, only up to four
arguments are supported. We can always add more, of course, but this
should be good enough until we move to a later MSVC that has full
support for variadic templates.
Inspired by std::experimental::optional from the "Library Fundamentals" C++ TS.
Reviewed by David Blaikie.
llvm-svn: 218732
|
|
|
|
|
|
|
|
|
|
| |
This takes a single argument convertible to T, and
- if the Optional has a value, returns the existing value,
- otherwise, constructs a T from the argument and returns that.
Inspired by std::experimental::optional from the "Library Fundamentals" C++ TS.
llvm-svn: 218618
|
|
|
|
| |
llvm-svn: 218142
|
|
|
|
| |
llvm-svn: 217786
|
|
|
|
|
|
| |
ArrayRef-of-pointer conversions introduced in r216709
llvm-svn: 216830
|
|
|
|
| |
llvm-svn: 216821
|
|
|
|
|
|
| |
just letting them be implicitly created.
llvm-svn: 216525
|
|
|
|
| |
llvm-svn: 216008
|
|
|
|
| |
llvm-svn: 215483
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's not clear what the semantics of a self-move should be. The
consensus appears to be that a self-move should leave the object in a
moved-from state, which is what our existing move assignment operator
does.
However, the MSVC 2013 STL will perform self-moves in some cases. In
particular, when doing a std::stable_sort of an already sorted APSInt
vector of an appropriate size, one of the merge steps will self-move
half of the elements.
We don't notice this when building with MSVC, because MSVC will not
synthesize the move assignment operator for APSInt. Presumably MSVC
does this because APInt, the base class, has user-declared special
members that implicitly delete move special members. Instead, MSVC
selects the copy-assign operator, which defends against self-assignment.
Clang, on the other hand, selects the move-assign operator, and we get
garbage APInts.
llvm-svn: 215478
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the MinGW32 and Cygwin types from the OSType enumeration. These values
are represented via environments of Windows. It is a source of confusion and
needlessly clutters the code. The cost of doing this is that we must sink the
check for them into the normalization code path along with the spelling.
Addresses PR20592.
llvm-svn: 215303
|
|
|
|
|
|
| |
Self assignment would lead to buckets of garbage, causing quadratic probing to hang.
llvm-svn: 214790
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
checking whether the ArrayRef is equal to an explicit list of arguments.
This is particularly easy to implement even without variadic templates
because ArrayRef happens to be homogeneously typed. As a consequence we
can use a "clever" wrapper type and default arguments to capture in
a single method many arguments as well as *how many* arguments the user
specified.
Thanks to Dave Blaikie for helping me pull together this little helper.
Suggestions for how to improve or generalize it are of course welcome.
I'll be using it immediately in my follow-up patch. =D
llvm-svn: 214041
|
|
|
|
|
|
|
| |
Add a `MapVector::remove_if()` that erases items in bulk in linear time,
as opposed to quadratic time for repeated calls to `MapVector::erase()`.
llvm-svn: 213090
|
|
|
|
|
|
|
|
|
|
|
|
| |
Actually update the changed indexes in the map portion of `MapVector`
when erasing from the middle. Add a unit test that checks for this.
Note that `MapVector::erase()` is a linear time operation (it was and
still is). I'll commit a new method in a moment called
`MapVector::remove_if()` that deletes multiple entries in linear time,
which should be slightly less painful.
llvm-svn: 213084
|
|
|
|
|
|
|
|
| |
llvm::Triple::getARMCPUForArch().
Suggested by Eric Christopher.
llvm-svn: 212846
|
|
|
|
|
|
|
|
| |
The slice(N, M) interface is powerful but not concise when wanting to
drop a few elements off of an ArrayRef, fix this by adding a drop_back
method.
llvm-svn: 212370
|
|
|
|
|
|
|
|
|
|
|
|
| |
private, but non-deleted, move members.
Certain versions of GCC (~4.7) couldn't handle the SFINAE on access
control, but with "= delete" (hidden behind a macro for portability)
this issue is worked around/addressed.
Patch by Agustín Bergé
llvm-svn: 211525
|
|
|
|
|
|
| |
functions to return unsigned instead of bool.
llvm-svn: 211393
|
|
|
|
|
|
|
|
|
|
|
|
| |
container concept."
This reverts commit r211309.
It looks like it broke some bots:
http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/15563/steps/compile/logs/stdio
llvm-svn: 211328
|
|
|
|
|
|
|
|
| |
container concept.
Patch by Agustín Bergé.
llvm-svn: 211309
|
|
|
|
|
|
| |
llvm::OwningPtr is superseded by std::unique_ptr.
llvm-svn: 211259
|
|
|
|
| |
llvm-svn: 210665
|
|
|
|
|
|
| |
pointers. Simpliies all in tree call sites. No functional change.
llvm-svn: 210638
|
|
|
|
| |
llvm-svn: 210507
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 210495
|
|
|
|
| |
llvm-svn: 210442
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 210436
|
|
|
|
|
|
|
|
| |
when inserting repeated elements.
Also split and improve tests a bit.
llvm-svn: 210433
|
|
|
|
| |
llvm-svn: 210432
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 210430
|
|
|
|
|
|
|
|
| |
(& 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)
llvm-svn: 210429
|
|
|
|
|
|
| |
Because we don't have a separate negate( ) function, 0 - NaN does double-duty as the IEEE-754 negate( ) operation, which (unlike most FP ops) *does* attach semantic meaning to the signbit of NaN.
llvm-svn: 210428
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
llvm-svn: 210426
|
|
|
|
| |
llvm-svn: 208388
|
|
|
|
| |
llvm-svn: 208362
|
|
|
|
| |
llvm-svn: 208361
|
|
|
|
| |
llvm-svn: 208359
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 207663
|
|
|
|
|
|
| |
clear it out.
llvm-svn: 207471
|
|
|
|
|
|
|
| |
never actually compared for equality two pointer unions that were equal.
Fortunately, things seem to work. =]
llvm-svn: 207468
|
|
|
|
| |
llvm-svn: 207466
|
|
|
|
|
|
| |
around pointer types.
llvm-svn: 207465
|
|
|
|
|
|
|
|
|
|
| |
It's fishy to be changing the `std::vector<>` owned by the iterator, and
no one actual does it, so I'm going to remove the ability in a
subsequent commit. First, update the users.
<rdar://problem/14292693>
llvm-svn: 207252
|