llvm-svn: 71872

When word-wrapping, be more defensive about a ridiculously small number of columns. Fixes <rdar://problem/6892178>

llvm-svn: 71870

instantiating the definition of a function from a template.

llvm-svn: 71869

llvm-svn: 71861

buffer.  This caused exciting nonsense like this:

$ clang t.c -fsyntax-only -UMACRO
In file included from <built-in>:104:
<command line>:1:14: warning: extra tokens at end of #undef directive [-Wextra-tokens]
#undef MACRO 1
             ^
             //
1 diagnostic generated.

rdar://6891800

llvm-svn: 71860

Fix crash when deriving the enclosing summary of a method whose first selector slot has a null IdentifierInfo*.  This happens when analyzing Growl.

llvm-svn: 71857

llvm-svn: 71847

llvm-svn: 71843

Cleanup internal checks bug reporting, allowing intermediate diagnostics to be generated for bad argument warnings, bad branches, etc.

llvm-svn: 71838

llvm-svn: 71832

PathDiagnosticLocation::asRange(): for a PathDiagnosticLocation, the range of a DeclStmt is only the decl, not
the decl + initializer.

llvm-svn: 71831

loop body when generating 'Looping back to the head of the loop'
diagnostics.

llvm-svn: 71829

llvm-svn: 71825

variables.  For this to work, the backend needs to handle more complex
forms for locations.

A typical utterance would be:

        %forwarding = getelementptr %0* %use_by_ref, i32 0, i32 1               ; <i8**> [#uses=1]
        %0 = load i8** %forwarding              ; <i8*> [#uses=1]
        %1 = bitcast i8* %0 to %0*              ; <%0*> [#uses=1]
        %x = getelementptr %0* %1, i32 0, i32 4         ; <i32*> [#uses=1]
        %2 = bitcast i32* %x to { }*            ; <{ }*> [#uses=1]
        call void @llvm.dbg.declare({ }* %2, { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable to { }*))

Presently when selection finds something it doesn't understand, it
just avoids generating any information, which is safe, just
incomplete.  Radar 6867696

llvm-svn: 71824

llvm-svn: 71823

llvm-svn: 71822

llvm-svn: 71818

method is a qualified id which conforms to the matching type
of its method declaration.

llvm-svn: 71817

llvm-svn: 71816

functions of class templates. Only compound statements and expression
statements are currently implemented.

llvm-svn: 71814

llvm-svn: 71802

llvm-svn: 71800

Introduce a stack of instantiation scopes that are used to store the mapping from variable declarations that occur within templates to their instantiated counterparts

llvm-svn: 71799

llvm-svn: 71797

template to the FunctionDecls from which they were instantiated. This
is a necessary first step to support instantiation of the definitions
of such functions, but by itself does essentially nothing.

llvm-svn: 71792

llvm-svn: 71790

llvm-svn: 71788

llvm-svn: 71786

llvm-svn: 71780

with sentinel attribute.

llvm-svn: 71778

 - Otherwise we emit internal names with embedded '\01' characters,
   which confuses some tools.

 - Ideally all the code which wants to get a "display name" for the
   given function should follow one code path, but this should be a
   monotonic improvement for now.

llvm-svn: 71774

declared as a "class", or vice-versa. This warning is under the
control of -Wmismatched-tags, which is off by default.

llvm-svn: 71773

llvm-svn: 71763

emit the correct "display name". I suspect we need more work here, see
FIXME for example.

llvm-svn: 71761

Add return type checking for overriding virtual functions. We currently don't check covariance but that's next.

llvm-svn: 71759

  template<typename T>
  struct X {
    struct Inner;
  };

  template struct X<int>::Inner;

This change is larger than it looks because it also fixes some
a problem with nested-name-specifiers and tags. We weren't requiring
the DeclContext associated with the scope specifier of a tag to be
complete. Therefore, when looking for something like "struct
X<int>::Inner", we weren't instantiating X<int>. 

This, naturally, uncovered a problem with member pointers, where we
were requiring the left-hand side of a member pointer access
expression (e.g., x->*) to be a complete type. However, this is wrong:
the semantics of this expression does not require a complete type (EDG
agrees).

Stuart vouched for me. Blame him.

llvm-svn: 71756

dispatch arguments which have sentinel attribute.

llvm-svn: 71737

debug info.

llvm-svn: 71736

llvm-svn: 71721

llvm-svn: 71720