Summary:
Some valid pre-C++11 constructs change meaning when lexed in C++11
mode, e.g.
#define x(_a) printf("foo"_a);
(example from http://llvm.org/bugs/show_bug.cgi?id=16342). "foo"_a is treated as
a user-defined string literal when parsed in C++11 mode.
In order to deal with this correctly, we need to set lexing mode according to
which standard the code conforms to. We already have a configuration value for
this (FormatStyle.Standard), which seems to be appropriate to use in this case
as well.

Reviewers: klimek

CC: cfe-commits, gribozavr

Differential Revision: http://llvm-reviews.chandlerc.com/D1028

llvm-svn: 185149

llvm-svn: 185148

llvm-svn: 185147

llvm-svn: 185146

llvm-svn: 185145

llvm-svn: 185144

llvm-svn: 185143

llvm-svn: 185142

llvm-svn: 185141

Add a test.

llvm-svn: 185140

llvm-svn: 185139

[ASan][OSX] Fix the incorrect malloc_create_zone() implementation that led to out-of-bounds mprotect()s
(https://code.google.com/p/address-sanitizer/issues/detail?id=203)
Add a test.

llvm-svn: 185138

llvm-svn: 185137

llvm-svn: 185136

No functionality change.
It should suffice to check the type of a debug info metadata, instead of
calling Verify. For cases where we know the type of a DI metadata, use
assert.

Also update testing cases to make them conform to the format of DI classes.

llvm-svn: 185135

llvm-svn: 185134

llvm-svn: 185133

module deserialization / merging, and more laziness here is general goodness.

llvm-svn: 185132

llvm-svn: 185131

llvm-svn: 185130

llvm-svn: 185129

llvm-svn: 185128

llvm-svn: 185127

* Don't try to create parent directories in unique_file. It had two problem:
   * It violates the contract that it is atomic. If the directory creation
     success and the file creation fails, we would return an error but the
     file system was modified.
   * When creating a temporary file clang would have to first check if the
     parent directory existed or not to avoid creating one when it was not
     supposed to.

* More efficient implementations of createUniqueDirectory and the unique_file
  that produces only the file name. Now all 3 just call into a static
  function passing what they want (name, file or directory).

Clang also has to be updated, so tests might fail if a bot picks up this commit
and not the corresponding clang one.

llvm-svn: 185126

Templatize connectAtomsWithLayoutEdge() so that it can handle other types of
defined atoms.

llvm-svn: 185125

llvm-svn: 185124

llvm-svn: 185123

radar://14169017

llvm-svn: 185122

llvm-svn: 185121

llvm-svn: 185120

llvm-svn: 185119

This replaces a long list of declarations for visitor functions with
a list generated from DeclNodes.inc.  Nothing really interesting came
out of it; we had comprehensive coverage anyway
(excluding FriendTemplateDecls).

llvm-svn: 185118

initialized during aggregate initialization of the surrounding structure.

llvm-svn: 185117

Differential Revision: http://llvm-reviews.chandlerc.com/D1051

llvm-svn: 185115

a zero-argument createNullPtrType function for creating the canonical
nullptr type.

Differential Revision: http://llvm-reviews.chandlerc.com/D1050

llvm-svn: 185114

llvm-svn: 185113

passing arguments in the fixed style.

We have an abstraction for deciding this, but it's (1) deep in
IR-generation, (2) necessarily tied to exact argument lists, and
(3) triggered by unprototyped function types, which we can't
legitimately make in C++ mode.  So this solution, wherein Sema
rewrites the function type to an exact prototype but leaves the
variadic bit enabled so as to request x86-64-like platforms to
pass the extra variadic info, is very much a hack, but it's one
that works in practice on the platforms that LLDB will support
in the medium term --- the only place we know of where it's a
problem is instance methods in Windows, where variadic functions
are implicitly cdecl.  We may have a more abstracted base on which
to build a solution by then.

rdar://13731520

llvm-svn: 185112

Revert "Revert "[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float.""

This reverts commit r185099.

Looks like both the ppc-64 and mips bots are still failing after I reverted this
change.

Since:

1. The mips bot always performs a clean build,
2. The ppc64-bot failed again after a clean build (I asked the ppc-64
maintainers to clean the bot which they did... Thanks Will!),

I think it is safe to assume that this change was not the cause of the failures
that said builders were seeing. Thus I am recomitting.

llvm-svn: 185111

This reverts commit r184817. The failure Chandler was seeing was most likely the
bug that Bob Wilson fixed in r184870 (which was a bug caught by these tests).

To be safe, I just checked again on x86-64 mac os x/linux that this test passed
(which it did).

llvm-svn: 185110

its only caller with a FIXME explaining why it's bogus.

llvm-svn: 185109