LLVM/Clang basically don't use such comments and for Google-style,
include-lines are explicitly exempt from the column limit. Also, for
most cases, where the column limit is violated, the "better" solution
would be to move the comment to before the include, which clang-format
cannot do (yet).

llvm-svn: 181191

clang-format did not indent any declarations/definitions when breaking
after the type. With this change, it indents for all declarations but
does not indent for function definitions, i.e.:

Before:
const SomeLongTypeName&
some_long_variable_name;
typedef SomeLongTypeName
SomeLongTypeAlias;
const SomeLongReturnType*
SomeLongFunctionName();
const SomeLongReturnType*
SomeLongFunctionName() { ... }

After:
const SomeLongTypeName&
    some_long_variable_name;
typedef SomeLongTypeName
    SomeLongTypeAlias;
const SomeLongReturnType*
    SomeLongFunctionName();
const SomeLongReturnType*
SomeLongFunctionName() { ... }

While it might seem inconsistent to indent function declarations, but
not definitions, there are two reasons for that:
- Function declarations are very similar to declarations of function
type variables, so there is another side to consistency to consider.
- There can be many function declarations on subsequent lines and not
indenting can make them harder to identify. Function definitions
are already separated by their body and not indenting
makes the function name slighly easier to find.

llvm-svn: 181187

__alignof__ of a field.

This problem can only happen in C++11.

Also do some petty optimizations.

rdar://13784901

llvm-svn: 181185

llvm-svn: 181184

This seems to be more common in LLVM, Google and Chromium.

Before:
class AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA :
    public BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
    public CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC {
};

After:
class AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    : public BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
      public CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC {
};

llvm-svn: 181183

Before: template <class ... Ts> void Foo(Ts ... ts) { Foo(ts ...); }
After:  template <class... Ts> void Foo(Ts... ts) { Foo(ts...); }
llvm-svn: 181182

llvm-svn: 181181

Fix assert if __extension__ or _Generic is used when initializing a char array from a string literal.

llvm-svn: 181174

llvm-svn: 181173

assignments in constant expressions. No significant functionality changes
(slight improvement to potential constant expression checking). 

llvm-svn: 181170

llvm-svn: 181166

I was not able to find a case (other than the fix in r181163) where this
makes a difference, but it is a more obviously correct API to have.

llvm-svn: 181165

Patch by Robert Wilhelm.

llvm-svn: 181164

This fixes pr14958. I will audit other calls to isExternCContext to see
if there are any similar bugs left.

llvm-svn: 181163

llvm-svn: 181159

llvm-svn: 181158

llvm-svn: 181150

llvm-svn: 181140

Patch by Robert Wilhelm.

llvm-svn: 181139

Properly parsing __declspec(safebuffers), though there is no semantic hookup.  For more information about safebuffers, see MSDN: http://msdn.microsoft.com/en-us/library/dd778695(v=vs.110).aspx

llvm-svn: 181123

llvm-svn: 181122

and specified the triple.

llvm-svn: 181115

No functionality change.

llvm-svn: 181114

llvm-svn: 181113

libgcc provides a __clear_cache intrinsic on AArch64, much like it
does on 32-bit ARM.

llvm-svn: 181111

and mark "clarifying memory allocation" as done, since it turns out that our
optimizations here (such as they are) already conform to the new rules.

llvm-svn: 181110

llvm-svn: 181109

Missing (somewhat ironically) is support for the new deduction rules
in lambda functions, plus PCH support for return type patching.

llvm-svn: 181108

to use. This makes very little difference right now (other than suppressing
follow-on errors in some cases), but will matter more once we support deduced
return types (we don't want expressions with undeduced return types in the
AST).

llvm-svn: 181107

llvm-svn: 181103

- Sema tests added and CodeGen tests are pending

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

llvm-svn: 181101

the list of Decls for a given DeclContext.  This
is useful for LLDB's implementation of
FindExternalLexicalDecls.

llvm-svn: 181093

llvm-svn: 181092

conversion-type-id, in preparation for this becoming valid in c++1y mode.
No functionality change; small diagnostic improvement.

llvm-svn: 181089

[analyzer;alternate edges] start experimenting with control flow "barriers" to prevent an edge being optimized away.

llvm-svn: 181088

llvm-svn: 181087

llvm-svn: 181086

[analyzer; alternate edges] - merge control edges where we descend to a subexpression and pop back out.

llvm-svn: 181085

This change required some minor changes to LocationContextMap to have it map
from PathPieces to LocationContexts instead of PathDiagnosticCallPieces to
LocationContexts.  These changes are in the other diagnostic
generation logic as well, but are functionally equivalent.

Interestingly, this optimize requires delaying "cleanUpLocation()" until
later; possibly after all edges have been optimized.  This is because
we need PathDiagnosticLocations to refer to the semantic entity (e.g. a statement)
as long as possible.  Raw source locations tell us nothing about
the semantic relationship between two locations in a path.

llvm-svn: 181084

These were being dropped due a transcription mistake from the original
algorithm.

llvm-svn: 181083