llvm-svn: 71823

llvm-svn: 71822

llvm-svn: 71820

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

llvm-svn: 71793

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

llvm-svn: 71790

llvm-svn: 71788

llvm-svn: 71786

llvm-svn: 71780

with sentinel attribute.

llvm-svn: 71778

llvm-svn: 71776

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

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

compared to gcc. This is worrisome, but I believe we are doing the
"correct" thing, and if I recall correctly I previously verified this
versus MSVC.

llvm-svn: 71723

llvm-svn: 71721

llvm-svn: 71720

cf_returns_retained. Currently this attribute can now be applied to any
Objective-C method or C function that returns a pointer or Objective-C object
type.

Modify the tablegen definition of diagnostic 'warn_attribute_wrong_decl_type' to
expect that the diagnostics infrastructure will add quotes around the attribute
name when appropriate. Alonq with this change, I modified the places where this
warning is issued to passed the attribute's IdentifierInfo* instead of having a
hard-coded C constant string.

llvm-svn: 71718

llvm-svn: 71716

of class members (recursively). Only member classes are actually
instantiated; the instantiation logic for member functions and
variables are just stubs.

llvm-svn: 71713

Disable access control by default. It can be enabled with the -faccess-control option. When we have better support for it, we can enable it by default again.

llvm-svn: 71706

llvm-svn: 71701

llvm-svn: 71700

llvm-svn: 71699