Instead, use the location of the call to print the note.

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

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

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

Adding an QualType::isNull() check.



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

Summary:
Added parseConfiguration method, which reads FormatStyle from YAML
string. This supports all FormatStyle fields and an additional BasedOnStyle
field, which can be used to specify base style.

Reviewers: djasper, klimek

Reviewed By: djasper

CC: cfe-commits

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

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

With certain styles:
Before: delete* x;
After:  delete *x;

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

This is just a slight improvement for the fix in r181299, which fixes
formatting the very last line of a file.

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

Emacs seems to have a line that is just past the last character of the
buffers content. This needs to be handled specially so that clang-format
is not called with an invalid -offset.

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

[analyzer; alternate edges] simplify optimization rules to look at control-flow conditions to prune edges.

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

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

unnamed bitfields.

Unnamed bitfields won't have an explicit copy operation
in the AST, which breaks the strong form of the invariant.

rdar://13816940

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

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

This fixes a crash due to SourceManager::getLocForEndOfFile() returning an off-by-one location
when the the FileID is for an empty file.

rdar://13803893

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

C++1y: an assignment operator is implicitly 'constexpr' if it would only call 'constexpr' assignment operators for a literal class type.


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

 - fix paper links to point to isocpp.org, where most of the papers are already up
 - update "SVN" features to "Clang 3.3" to distinguish them from features which we
   complete after the branch
 - document use of -std=c++1y to enable c++1y support


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

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

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

[analyzer; alternate arrows] don't increment the path iterator when we just deleted the next iterator.

This is an optimization.  It is possible that by deleting the next
edge we will pattern match again at the current spot.

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

  - References to ObjC bit-field ivars are bit-field lvalues;
    fixes rdar://13794269, which got me started down this.
  - Introduce Expr::refersToBitField, switch a couple users to
    it where semantically important, and comment the difference
    between this and the existing API.
  - Discourage Expr::getBitField by making it a bit longer and
    less general-sounding.
  - Lock down on const_casts of bit-field gl-values until we
    hear back from the committee as to whether they're allowed.

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

Add missing initialization for Sema::CurScope. This is important for AST consumers which don't create a Parser. Pointed out by Tom Honermann.


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

Summary:
No functionality change.  The existing tests for this pragma only verify
that we can preprocess it.

Reviewers: rsmith

CC: cfe-commits

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

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

We can pass such an input-file-visiting ASTReaderListener to ASTReader::readASTFileControlBlock.

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

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

The one user has been changed to use getLValue on the compound literal
expression and then use the normal bindLoc to assign a value. No need
to special case this in the StoreManager.

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

This occurs because in C++11 the compound literal syntax can trigger a
constructor call via list-initialization. That is, "Point{x, y}" and
"(Point){x, y}" end up being equivalent. If this occurs, the inner
CXXConstructExpr will have already handled the object construction; the
CompoundLiteralExpr just needs to propagate that value forwards.

<rdar://problem/13804098>

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

Previously, this compound literal expression (a GNU extension in C++):

  (AggregateWithDtor){1, 2}

resulted in this AST:

 `-CXXBindTemporaryExpr [...] 'struct Point' (CXXTemporary [...])
   `-CompoundLiteralExpr [...] 'struct AggregateWithDtor'
     `-CXXBindTemporaryExpr [...] 'struct AggregateWithDtor' (CXXTemporary [...])
       `-InitListExpr [...] 'struct AggregateWithDtor'
         |-IntegerLiteral [...] 'int' 1
         `-IntegerLiteral [...] 'int' 2

Note the two CXXBindTemporaryExprs. The InitListExpr is really part of the
CompoundLiteralExpr, not an object in its own right. By introducing a new
entity initialization kind in Sema specifically for compound literals, we
avoid the treatment of the inner InitListExpr as a temporary.

 `-CXXBindTemporaryExpr [...] 'struct Point' (CXXTemporary [...])
   `-CompoundLiteralExpr [...] 'struct AggregateWithDtor'
     `-InitListExpr [...] 'struct AggregateWithDtor'
       |-IntegerLiteral [...] 'int' 1
       `-IntegerLiteral [...] 'int' 2

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

Add SystemZ support

This patch then adds all the usual platform-specific pieces for SystemZ:
driver support, basic target info, register names and constraints,
ABI info and vararg support.  It also adds new tests to verify pre-defined
macros and inline asm, and updates a test for the minimum alignment change.

This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall.  Thanks to all reviewers!

Patch by Richard Sandiford.



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

Allow targets to define minimum alignment for global variables

This patch adds a new common code feature that allows platform code to
request minimum alignment of global symbols.  The background for this is
that on SystemZ, the most efficient way to load addresses of global symbol
is the LOAD ADDRESS RELATIVE LONG (LARL) instruction.  This instruction
provides PC-relative addressing, but only to *even* addresses.  For this
reason, existing compilers will guarantee that global symbols are always
aligned to at least 2.  [ Since symbols would otherwise already use a
default alignment based on their type, this will usually only affect global
objects of character type or character arrays. ]  GCC also allows creating
symbols without that extra alignment by using explicit "aligned" attributes
(which then need to be used on both definition and each use of the symbol).

To enable support for this with Clang, this patch adds a
TargetInfo::MinGlobalAlign variable that provides a global minimum for the
alignment of every global object (unless overridden via explicit alignment
attribute), and adds code to respect this setting.  Within this patch, no
platform actually sets the value to anything but the default 1, resulting
in no change in behaviour on any existing target.

This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall.  Thanks to all reviewers!

Patch by Richard Sandiford.



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

We've added the RS880 variant in the LLVM backend to represent an R600
GPU with no vertex cache, so we need to update the GPU mappings for
-mcpu.

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

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

To pacify GCC warning about control reaching end of non-void function.

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

Summary: Patch based on a patch by Ehsan Akhgari.

Reviewers: djasper

Reviewed By: djasper

CC: cfe-commits, klimek

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

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

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).

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

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.

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

__alignof__ of a field.

This problem can only happen in C++11.

Also do some petty optimizations.

rdar://13784901

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

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

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 {
};

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

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

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

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

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


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