| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
This matches gnu archive behavior and since archive member order can change
which member is used, not changing the order on replacement looks like the
right thing to do.
This patch also refactors the logic for which archive member to keep and
whether to move it to a helper function (computeInsertAction). The
nesting in computeNewArchiveMembers was getting a bit confusing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186829 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
|
| |
GNU ar when not given the a or b modifiers replaces archive members in the
same location of the old ones. I am about to implement that in llvm-ar. For
now, just don't depend on the current llvm-ar behavior on this test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186823 91177308-0d34-0410-b5e6-96231b3b80d8
|
| |
|
|
|
|
|
| |
We were incorrectly computing where to insert a member if it was replacing
a previous member that was before the insert point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186792 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
We were only handling the 'a' and 'b' options during moves before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186721 91177308-0d34-0410-b5e6-96231b3b80d8
|
