Make test/Driver hermetic

Summary:
The includes shouldn't be there, use the compiler's built-in types/macros instead.

This is a follow-up to r217694, as discussed in:
  http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140908/114669.html

Test Plan: ninja check-clang

Reviewers: nlewycky, thakis, echristo, chandlerc

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D5348

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217743 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format: Add option to break before non-assignment operators.

This will allow:
  int aaaaaaaaaaaaaa =
      bbbbbbbbbbbbbb
      + ccccccccccccccc;

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217757 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format: Basic support for Java.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217759 91177308-0d34-0410-b5e6-96231b3b80d8
[ARM] Add ACLE predefines: maxmin, rounding and h/w integer division

Patch by Assad Hashmi!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217760 91177308-0d34-0410-b5e6-96231b3b80d8
Edit: Do not extend a removal to include trailing whitespace if we're at the end
of the file.

This would run past the end of the buffer. Sadly I don't have a great way to
test it, the only way to trigger the bug is having a removal fix it at the end
of the file, which none of our current warnings can generate.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217766 91177308-0d34-0410-b5e6-96231b3b80d8
When pretty printing attributes that have enumeration arguments, print the enumerator identifier (as a string literal) instead of the internal enumerator integral value.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217771 91177308-0d34-0410-b5e6-96231b3b80d8
Adding some FIXMEs to the attribute emitter code regarding whether pretty printing enumerators should use quoted string literals, or identifiers. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217781 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C SDK modernizer. Do not modernize an enum 
which already has the underlying interger type specification.
// rdar://1826225


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217783 91177308-0d34-0410-b5e6-96231b3b80d8
Pretty print attributes associated with record declarations.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217784 91177308-0d34-0410-b5e6-96231b3b80d8
Add -fseh-exceptions for MinGW-w64

This adds a flag called -fseh-exceptions that uses the native Windows
.pdata and .xdata unwind mechanism to throw exceptions. The other EH
possibilities are DWARF and SJLJ exceptions.

Patch by Martell Malone!

Reviewed By: asl, rnk

Differential Revision: http://reviews.llvm.org/D3419

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217790 91177308-0d34-0410-b5e6-96231b3b80d8
Fix memory leak of raw_ostreams in LogDiagnosticPrinter handling.

This is another case of conditional ownership (in this case a raw
reference, plus a boolean to indicate whether the referenced object
should be deleted). While it's not ideal, I prefer to make the ownership
explicit with a unique_ptr than using a boolean flag (though it does
make the reference and the unique_ptr redundant in the sense that they
both refer to the same memory). At some point we might write a reusable
conditional ownership pointer (a stateful custom deleter for a unique_ptr
may be appropriate).

Based on a patch from a patch by Anton Yartsev.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217791 91177308-0d34-0410-b5e6-96231b3b80d8
Teach Clang how to use response files when calling other tools

Patch by Rafael Auler!

This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.

I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.

I designed it to support different kinds of tools and
internationalisation needs:

- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
  support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )

With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.

Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.

In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.

Reviewers: asl, rafael, silvas

Reviewed By: silvas

Subscribers: silvas, rnk, thakis, cfe-commits

Differential Revision: http://reviews.llvm.org/D4897

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217792 91177308-0d34-0410-b5e6-96231b3b80d8
unique_ptrify ChainedDiagnosticConsumer's ctor parameters

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217793 91177308-0d34-0410-b5e6-96231b3b80d8
Use intrusive refcounted pointers to manage RopeRefCountString lifetime.

std::shared_ptr<char []> would be even nicer, but shared_ptr doesn't work
with arrays :(

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217798 91177308-0d34-0410-b5e6-96231b3b80d8
Create a emitCXXStructor function and make the existing emitCXXConstructor and
emitCXXDestructor static helpers.

A next patch will make it a helper in CGCXXABI.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217804 91177308-0d34-0410-b5e6-96231b3b80d8
Move emitCXXStructor to CGCXXABI.

A followup patch will address the code duplication.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217807 91177308-0d34-0410-b5e6-96231b3b80d8
Simplify the code a bit, NFC.

hasConstructorVariants is always true for MS and false for Itanium.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217809 91177308-0d34-0410-b5e6-96231b3b80d8
Reduce code duplication a bit more. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217811 91177308-0d34-0410-b5e6-96231b3b80d8
Reduce code duplication a bit more. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217813 91177308-0d34-0410-b5e6-96231b3b80d8
Major rewrite of linking strategy for sanitizer runtimes on Linux.

Change 1: we used to add static sanitizer runtimes at the
very beginning of the linker invocation, even before crtbegin.o, which
is gross and not correct in general. Fix this: now addSanitizerRuntimes()
adds all sanitizer-related link flags to the end of the linker invocation
being constructed. It means, that we should call this function in the
correct place, namely, before AddLinkerInputs() to make sure sanitizer
versions of library functions will be preferred.

Change 2: Put system libraries sanitizer libraries depend on at the
end of the linker invocation, where all the rest system libraries are
located. Respect --nodefaultlibs and --nostdlib flags. This is another way
to fix PR15823. Original fix landed in r215940 put "-lpthread" and friends
immediately after static ASan runtime, before the user linker inputs.
This caused significant slowdown in dynamic linker for large binaries
linked against thousands of shared objects. Instead, to mark system
libraries as DT_NEEDED we prepend them with "--no-as-needed" flag,
discarding the "-Wl,--as-needed" flag that could be provided by the user.

Otherwise, this change is a code cleanup. Instead of having a special method
for each sanitizer, we introduce a function collectSanitizerRuntimes() that
analyzes -fsanitize= flags and returns the set of static and shared
libraries that needs to be linked.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217817 91177308-0d34-0410-b5e6-96231b3b80d8