declaration references. The key realization is that dependent Decls,
which actually require instantiation, can only refer to the current
instantiation or members thereof. And, since the current context
during instantiation contains all of those members of the current
instantiation, we can simply find the real instantiate that matches up
with the "current instantiation" template.

llvm-svn: 72486

references. There are several smallish fixes here:

  - Make sure we look through template parameter scope when
    determining whether we're parsing a nested class (or nested class
    *template*). This makes sure that we delay parsing the bodies of
    inline member functions until after we're out of the outermost
    class (template) scope.
  - Since the bodies of member functions are always parsed
    "out-of-line", even when they were declared in-line, teach
    unqualified name lookup to look into the (semantic) parents.
  - Use the new InstantiateDeclRef to handle the instantiation of a
    reference to a declaration (in DeclRefExpr), which drastically
    simplifies template instantiation for DeclRefExprs.
  - When we're instantiating a ParmVarDecl, it must be in the current
    instantiation scope, so only look there.

Also, remove the #if 0's and FIXME's from the dynarray example, which
now compiles and executes thanks to Anders and Eli.

llvm-svn: 72481

instantiation of a declaration from the template version (or version
that lives in a template) and a given set of template arguments. This
needs much, much more testing, but it suffices for simple examples
like

  typedef T* iterator;
  iterator begin();

llvm-svn: 72461

llvm-svn: 72440

expressions. We are now missing template instantiation logic for only
three classes of expressions:
  - Blocks-related expressions (BlockExpr, BlockDeclRefExpr)
  - C++ default argument expressions
  - Objective-C expressions

Additionally, our handling of DeclRefExpr is still quite poor, since
it cannot handle references to many kinds of declarations.

As part of this change, converted the TemplateExprInstantiator to use
iteration through all of the expressions via clang/AST/StmtNodes.def,
ensuring that we don't forget to add template instantiation logic for
any new expression node kinds.

llvm-svn: 72303

llvm-svn: 72301

llvm-svn: 72299

call other member functions of class templates, including after
template instantiation. No functionality change.

llvm-svn: 72282

expressions. This change introduces another AST node,
CXXUnresolvedMemberExpr, that captures member references (x->m, x.m)
when the base of the expression (the "x") is type-dependent, and we
therefore cannot resolve the member reference yet.

Note that our parsing of member references for C++ is still quite
poor, e.g., we don't handle x->Base::m or x->operator int.

llvm-svn: 72281

llvm-svn: 72236

llvm-svn: 72234

can. Also, delay semantic analysis of initialization for
value-dependent as well as type-dependent expressions, since we can't
always properly type-check a value-dependent expression.

llvm-svn: 72233

llvm-svn: 72229

llvm-svn: 72220

llvm-svn: 72218

llvm-svn: 72217

llvm-svn: 72216

redundant functionality. The result (ASTOwningVector) lives in
clang/Parse/Ownership.h and is used by both the parser and semantic
analysis. No intended functionality change.

llvm-svn: 72214

llvm-svn: 72199

passes the "isStmtExpr" flag, to suppress warnings about unused
expressions.

llvm-svn: 72190

llvm::SmallVector that owns all of the AST nodes inside of it. This
RAII class is used to ensure proper destruction of AST nodes when
template instantiation fails.

llvm-svn: 72186

temporaries are generated for some object-constructing expressions in
templates that are not type-dependent. 

Also, be sure to introduce the variable from a CXXConditionDeclExpr
into the set of instantiated local variables.

llvm-svn: 72185

due to C++ type construction of the form T(a1, a2, ..., aN).

llvm-svn: 72183

describe the construction of a value of a given type using function
syntax, e.g.,
  
  T(a1, a2, ..., aN)

when the type or any of its arguments are type-dependent. In this
case, we don't know what kind of type-construction this will be: it
might construct a temporary of type 'T' (which might be a class or
non-class type) or might perform a conversion to type 'T'. Also,
implement printing of and template instantiation for this new
expression type. Due to the change in Sema::ActOnCXXTypeConstructExpr,
our existing tests cover template instantiation of this new expression
node.

llvm-svn: 72176

need template instantiation logic. Remove one FIXME by instantiating
the callee in a non-type-dependent CXXOperatorCallExpr.

llvm-svn: 72145

llvm-svn: 72144

llvm-svn: 72143

and it isn't clear exactly what it's supposed to mean. Thanks Eli!

llvm-svn: 72142

llvm-svn: 72139

llvm-svn: 72134

llvm-svn: 72129

operator in C++, and verify that template instantiation for the
condition operator does the right thing.

llvm-svn: 72127

llvm-svn: 72126

llvm-svn: 72119

llvm-svn: 72081

easier than expected because of the limitation that subscript
operators must be member functions.

llvm-svn: 72076

llvm-svn: 72058

Implement instantiation of a few boring, simple expressions. I don't think these are testable yet, though.

llvm-svn: 71953

llvm-svn: 71936

llvm-svn: 71896