In CallInst, op_end() points at the callee, which we don't want to iterate over
when just iterating over arguments. Now take this into account when returning
a iterator_range from arg_operands. Similar reasoning for InvokeInst.

Also adds a unit test to verify this actually works as expected.

llvm-svn: 204851

It is impossible to create a hard link to a non existing file, so create a
dummy file, create the link an delete the dummy file.

On windows one cannot remove the current directory, so chdir first.

llvm-svn: 204719

  - create_link doesn't work for nonexistent file.
  - remove cannot remove working directory.

llvm-svn: 204579

llvm-svn: 204533

llvm-svn: 204426

[Support] Make sure sys::fs::remove can remove symbolic links and make sure LockFileManager can handle a symbolic link that points nowhere.

llvm-svn: 204422

We would emit a pair of double quotes inside a pair of single quotes.
Just use a pair of single quotes.

llvm-svn: 204312

llvm-svn: 204132

Also changes the iterators to return actual DI type over MDNode.

llvm-svn: 204130

order to use the single assignment. That's probably worth doing for
a lot of these types anyways as they may have non-trivial moves and so
getting copy elision in more places seems worthwhile.

I've tried to add some tests that actually catch this mistake, and one
of the types is now well tested but the others' tests still fail to
catch this. I'll keep working on tests, but this gets the core pattern
right.

llvm-svn: 203780

llvm-svn: 203679

Otherwise gcc 4.8.2 generates a warning.

llvm-svn: 203671

llvm-svn: 203662

Add a utility function to convert the Windows path separator to Unix style path
separators.  This is used by a subsequent change in clang to enable the use of
Windows SDK headers on Linux.

llvm-svn: 203611

Before this patch the unix code for creating hardlinks was unused. The code
for creating symbolic links was implemented in lib/Support/LockFileManager.cpp
and the code for creating hard links in lib/Support/*/Path.inc.

The only use we have for these is in LockFileManager.cpp and it can use both
soft and hard links. Just have a create_link function that creates one or the
other depending on the platform.

llvm-svn: 203596

In import thunk, jmp is:
  - On x86, 0xFF 0x25 [disp32].
  - On x64, 0xFF 0x25 [pcrel32].

See also my r144178.

llvm-svn: 203523

  - Use constructor instead of initializer list.
  - Disable ManyUnusedBits for now.

llvm-svn: 203436

lines under 80-columns, etc.

llvm-svn: 203434

horrible smart pointer by std::unique_ptr and strict move semantics, rip
this out.

llvm-svn: 203392

it is available. Also make the move semantics sufficiently correct to
tolerate move-only passes, as the PassManagers *are* move-only passes.

llvm-svn: 203391

llvm-svn: 203387

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.

llvm-svn: 203375

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.

llvm-svn: 203374

llvm-svn: 203346

EXPECT_TRUE/FALSE is also more idiomatic for booleans than EXPECT_EQ

llvm-svn: 203284

Previously, the assertions in PointerIntPair would try to calculate the value
(1 << NumLowBitsAvailable); the inferred type here is 'int', so if there were
more than 31 bits available we'd get a shift overflow.

Also, add a rudimentary unit test file for PointerIntPair.

llvm-svn: 203273

Simplify the remaining ones a bit.

llvm-svn: 203249

No functionality change.

llvm-svn: 203242

This is a preliminary setup change to support a renaming of Windows target
triples.  Split the object file format information out of the environment into a
separate entity.  Unfortunately, file format was previously treated as an
environment with an unknown OS.  This is most obvious in the ARM subtarget where
the handling for macho on an arbitrary platform switches to AAPCS rather than
APCS (as per Apple's needs).

llvm-svn: 203160

This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.

llvm-svn: 203083

consistent with every other sub-library header in LLVM.

llvm-svn: 203065

already lives.

llvm-svn: 203046

already lives.

llvm-svn: 203038

When using a //net/ path, we were transforming the trailing / into a '.'
when the path was just the root path and we were iterating backwards.
Forwards iteration and other kinds of root path (C:\, /) were already
correct.

llvm-svn: 202999

This will allow external callers of these functions to switch over time
rather than forcing a breaking change all a once. These particular
functions were determined by building clang/lld/lldb.

llvm-svn: 202959

llvm-svn: 202957

This will make the transition to unique_ptr easier by allowing more
incremental changes.

llvm-svn: 202949

now. ;] Tested on both a static and shared CMake build. Hopefully the
bots will agree.

llvm-svn: 202844

source file had already been moved. Also move the unittest into the IR
unittest library.

This may seem an odd thing to put in the IR library but we only really
use this with instructions and it needs the LLVM context to work, so it
is intrinsically tied to the IR library.

llvm-svn: 202842

a bit surprising, as the class is almost entirely abstracted away from
any particular IR, however it encodes the comparsion predicates which
mutate ranges as ICmp predicate codes. This is reasonable as they're
used for both instructions and constants. Thus, it belongs in the IR
library with instructions and constants.

llvm-svn: 202838