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

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

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

llvm-svn: 71698

coercion to be specified which truncates padding bits. It would be
nice to still have the assert, but we don't have any API call for the
unpadding size of a type yet.

llvm-svn: 71695

templates. In particular:
  - An explicit instantiation can follow an implicit instantiation (we
  were improperly diagnosing this as an error, previously).
  - In C++0x, an explicit instantiation that follows an explicit
  specialization of the same template specialization is ignored. In
  C++98, we just emit an extension warning.
  - In C++0x, an explicit instantiation must be in a namespace
  enclosing the original template. C++98 has no such requirement.

Also, fixed a longstanding FIXME regarding the integral type that is
used for the size of a constant array type when it is being instantiated.

llvm-svn: 71689

generation when EvalObjCMessageExpr() did not resolve the
ObjCInterfaceDecl* for a receiver when the receiver's symbolic value
wasn't being explicitly tracked.

llvm-svn: 71685

message dispatches (and function calls later). No change in
functionality.

llvm-svn: 71683

Used simple array for Selector build.

llvm-svn: 71674

Fix <rdar://problem/6880975> [format string] Assertion failed: (Arg < NumArgs && "Arg access out of range!").

For format string checking, only check the type of the format
specifier for non-vararg functions.

llvm-svn: 71672

llvm-svn: 71647

llvm-svn: 71643

It seems dubious to me that isIntegerType() returns true for
vectors of integers, but not complex integers.  This should 
probably be rethought, I'll file a bugzilla.

llvm-svn: 71640