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

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

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

llvm-svn: 71773

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

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

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

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

llvm-svn: 71683

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

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

rdar://6880104

llvm-svn: 71639

now until someone does it right

llvm-svn: 71638

rdar://6880573

llvm-svn: 71636

don't support.  While it would be nice to support this eventually,
this form is not common at all (just seen in gcc testsuite) and
it might be better to model vector_size as a type attribute anyway.
For now just emit a nice error on it.

llvm-svn: 71633

still aren't instantiating the definitions of class template members,
and core issues 275 and 259 will both affect the checking that we do
for explicit instantiations (but are not yet implemented).

llvm-svn: 71613

  template class X<int>;

This also cleans up the propagation of template information through
declaration parsing, which is used to improve some diagnostics.

llvm-svn: 71608

This implements rdar://6880449 - improve diagnostic for usage of "global register variable" GCC extension

llvm-svn: 71599

declarations.

llvm-svn: 71597

Per the FIXME, it might be interesting to track whether the inline keyword
was also used on the method, but for now we don't do this.  Testcase pending.

llvm-svn: 71589

TemplateArgumentList. This avoids the need to pass around
pointer/length pairs of template arguments lists, and will eventually
make it easier to introduce member templates and variadic templates.

llvm-svn: 71517

llvm-svn: 71489

specialization" within a C++ template, and permit name lookup into the
current instantiation. For example, given:

  template<typename T, typename U>
  struct X {
    typedef T type;

    X* x1;  // current instantiation
    X<T, U> *x2; // current instantiation
    X<U, T> *x3; // not current instantiation
    ::X<type, U> *x4; // current instantiation
    X<typename X<type, U>::type, U>: *x5; // current instantiation
  };

llvm-svn: 71471

With the introduction of nullptr, a template argument that refers to a declaration can now be NULL. Use cast_or_null appropriately

llvm-svn: 71412

template. The injected-class-name is either a type or a template,
depending on whether a '<' follows it. As a type, the
injected-class-name's template argument list contains its template
parameters in declaration order.

As part of this, add logic for canonicalizing declarations, and be
sure to canonicalize declarations used in template names and template
arguments. 

A TagType is dependent if the declaration it references is dependent.

I'm not happy about the rather complicated protocol needed to use
ASTContext::getTemplateSpecializationType.

llvm-svn: 71408

llvm-svn: 71405

ns_returns_retained, but do not include the other ownership attributes
we previously had.

llvm-svn: 71308

and we also want to tell which message is actually 
being sent.

llvm-svn: 71296

llvm-svn: 71278

llvm-svn: 71267

llvm-svn: 71248