global variable.

llvm-svn: 171919

llvm-svn: 171915

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: 171899

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

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

llvm-svn: 171884

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

llvm-svn: 171877

about _Static_assert with -pedantic.

llvm-svn: 171860

Fixes pr14835.

llvm-svn: 171857

This hopefully fixes the ARM buildbot.

llvm-svn: 171853

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

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

llvm-svn: 171820

perform the semantic checks associated with the destruction of that temporary.
It'll be destroyed at the end of the constructor.

llvm-svn: 171818

The test should be looking for gcrt0.o not crt0.o.  Clang was already printing
"gcrt0", but the test was looking for "{{.*}}crt0.o", and the .* regexp
consumed "g".

Patch by Brad Smith.

llvm-svn: 171815

llvm-svn: 171808

llvm-svn: 171801

llvm-svn: 171785

can create a VLA of class type. Fixes <rdar://problem/12151822>.

llvm-svn: 171783

Patch by Nick Lewycky. Fixes pr8703.

llvm-svn: 171781

list of classes, etc., make sure to look into protocol
definitions. // rdar://12958878

llvm-svn: 171777

check if the token was ever a macro name and annotate it if that's the case.

llvm-svn: 171776

DenseMap and the lookups associated with it.

Instead of lexing for preprocessor tokens, associating the annotation with the location in a map,
and later lookup in the map in order to adjust the cursor annotation, just annotate the cursor
while lexing for preprocessor tokens.

llvm-svn: 171775

Previously type/storage qualifiers would not be annotated as the declaration they belonged to.
Just use the resulting source range of getRawCursorExtent() which is more correct
than what AnnotateTokensWorker::Visit() was adjusting it to.

llvm-svn: 171774

this was ever a macro name and return a specific CXCursor_MacroExpansion cursor in such a case,
instead of the generic CXCursor_MacroDefinition.

Checking for macro name makes sure the identifier is not part of the identifier list in a
function macro.
While, in general, resolving identifiers in macro definitions to other macros may not be completely accurate,
it greatly improves functionality such as give-me-the-definition-of-this, which was not working at all
inside macro definitions.

llvm-svn: 171773

Better handle the blacklisting of known bad deallocators when symbol
escapes through a call to CFStringCreateWithBytesNoCopy.

Addresses radar://12702952.

llvm-svn: 171770

When a property is "inherited" through both a parent class and directly
through a protocol, we should not require the child to invalidate it
since the backing ivar belongs to the parent class.
(Fixes radar://12913734)

llvm-svn: 171769

<Declaration> tag

llvm-svn: 171763

Previous indent:
class A {
}
a;
void f() {
};

With this patch:
class A {
} a;
void f() {
}
;

The patch introduces a production for classes and structs, and parses
the rest of the line to the semicolon after the class scope.
This allowed us to remove a long-standing wart in the parser that would
just much the semicolon after any block.
Due to this suboptimal formating some tests were broken.

Some unrelated formatting tests broke; those hit a bug in the ast
printing, and need to be fixed separately.

llvm-svn: 171761

http://llvm-reviews.chandlerc.com/D234

Patch by Philip Craig!

llvm-svn: 171760

Following r168626, in class declaration or definition, there are a combination of syntactic locations 
where C++11 attributes could appear, and among those the only valid location permitted by standard is
between class-key and class-name. So for those attributes appear at wrong locations, fixit is used to 
move them to expected location and we recover by applying them to the class specifier.
 

llvm-svn: 171757

with respect to the lower "left-hand-side bitwidth" bits, even when negative);
see OpenCL spec 6.3j. This patch both implements this behaviour in the code
generator and "constant folding" bits of Sema, and also prevents tests
to detect undefinedness in terms of the weaker C99 or C++ specifications
from being applied. 

llvm-svn: 171755

First check only wrapped with i==8, second wrapped at i==2,8,18,28,...
This fix restores the intended behavior: i==8,18,28,...

Found with -fsanitize=integer.

llvm-svn: 171718