global variable.

llvm-svn: 171919

llvm-svn: 171917

llvm-svn: 171915

llvm-svn: 171913

struct variables with flexiable array members in
blocks (and lambdas). Issue error instead of
crashing in IRGen. // rdar://12655829

llvm-svn: 171912

llvm-svn: 171908

llvm-svn: 171906

llvm-svn: 171902

llvm-svn: 171899

llvm-svn: 171895

llvm-svn: 171894

-Wint-to-pointer-cast, added to match GCC's warning by the same name, doesn't
need to be in any other groups (as it isn't in any groups in GCC either).

Found in post-commit review by Ted Kremenek.

llvm-svn: 171893

llvm-svn: 171892

With the new setting, we are not going to inline any functions that are
more than 50 basic blocks. (The analyzer is 20% faster on several
especially bad benchmarks with the new default.)

llvm-svn: 171891

Before:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaa, *
                                                 aaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
    aaaaaaaaaaaaaaaaaaaaaaaaaaaa, *aaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

llvm-svn: 171890

Thanks to Dmitri Gribenko for the suggestion.

llvm-svn: 171889

In the source

  static void f();
  static void f();
  template<typename T>
  static void g() {
    f();
  }
  static void f() {
  }
  void h() {
    g<int>();
  }

the call to f refers to the second decl, but it is only marked used at the end
of the translation unit during instantiation, after the third f decl has been
linked in.

With this patch we mark all subsequent decls used, so that it is easy to check
if a symbol is used or not.

llvm-svn: 171888

llvm-svn: 171887

llvm-svn: 171885

This makes us more optimistic when matching reports in a changing code
base. Addresses Jordan's feedback for r171825.

llvm-svn: 171884

llvm-svn: 171883

before doing the comparison.

This is because we can't set "FirstInDeclGroup" consistently; for example, when visiting a DeclStmt we will set
it but we don't set it on the result of clang_getCursorDefinition for a reference of the same declaration.

llvm-svn: 171878

attribute when determining whether we need to see an implementation of
a property. Fixes <rdar://problem/12958191>.

llvm-svn: 171877

llvm-svn: 171875

llvm-svn: 171870

llvm-svn: 171865

In Clang/LLVM this seems to be the more common formatting for ##s. There
might still be case that we miss, but we'll fix those as we go along.

Before:

  #define A(X)
    void function ## X();

After:

  #define A(X)
    void function##X();

llvm-svn: 171862

about _Static_assert with -pedantic.

llvm-svn: 171860

Fixes pr14835.

llvm-svn: 171857

This is a first step towards supporting more complex structures such
as #ifs inside unwrapped lines. This patch mostly converts the array-based
UnwrappedLine into a linked-list-based UnwrappedLine. Future changes will
allow multiple children for each Token turning the UnwrappedLine into a
tree.

No functional changes intended.

llvm-svn: 171856

This hopefully fixes the ARM buildbot.

llvm-svn: 171853

I spotted someone confused about this, so remove the heading to make it
clear that they really are a part of Tooling.

llvm-svn: 171841

The availability implies default visibility, so it can change the computed
visibility.

llvm-svn: 171840

llvm-svn: 171834

Fixes <rdar://problem/12322000>.

llvm-svn: 171831

llvm-svn: 171830

that the case does not "contain" a declaration that is referenced "outside" of it,
otherwise we will emit un-compilable code.

llvm-svn: 171828

bits from the number of parameters. This brings the bitfields down from 33 bits
to 32 bits, reducing the size of Types by 4 bytes on 32-bit systems.

llvm-svn: 171827

The issue here is that if we have 2 leaks reported at the same line for
which we cannot print the corresponding region info, they will get
treated as the same by issue_hash+description. We need to AUGMENT the
issue_hash with the allocation info to differentiate the two issues.

Add the "hash" (offset from the beginning of a function) representing
allocation site to solve the issue.

We might want to generalize solution in the future when we decide to
track more than just the 2 locations from the diagnostics.

llvm-svn: 171825

This gives more flexibility to what could be stored as issue_hash.

llvm-svn: 171824