llvm-svn: 79143

still works.

llvm-svn: 78979

llvm-svn: 78471

to allow sharing of nodes. Simplifies some aspects of template
instantiation, and fixes both PR3444 and <rdar://problem/6757457>.

llvm-svn: 78450

tighten up the static type system.

llvm-svn: 78164

llvm-svn: 78102

template arguments, as in template specialization types. This permits
matching out-of-line definitions of members for class templates that
involve non-type template parameters.

llvm-svn: 77462

ActOnUninitializedDecl.

llvm-svn: 77211

Note that this also fixes a bug that affects non-template code, where we 
were not treating out-of-line static data members are "file-scope" variables,
and therefore not checking their initializers.

llvm-svn: 77002

Zaffanella, with tweaks from Abramo Bagnara.

llvm-svn: 76576

llvm-svn: 76274

llvm-svn: 76112

Note: One day, it might be useful to consider adding this info to DeclGroup (as the comments in FunctionDecl/VarDecl suggest). For now, I think this works fine. I considered moving this to ValueDecl (a common ancestor of FunctionDecl/VarDecl/FieldDecl), however this would add overhead to EnumConstantDecl (which would burn memory and isn't necessary).
llvm-svn: 75635

by distinguishing between substitution that occurs for template
argument deduction vs. explicitly-specifiad template arguments. This
is used both to improve diagnostics and to make sure we only provide
SFINAE in those cases where SFINAE should apply.

In addition, deal with the sticky issue where SFINAE only considers
substitution of template arguments into the *type* of a function
template; we need to issue hard errors beyond this point, as
test/SemaTemplate/operator-template.cpp illustrates.

llvm-svn: 74651

instantiation stack so that we provide a full instantiation
backtrace. Previously, we performed all of the instantiations implied
by the recursion, but each looked like a "top-level" instantiation.

The included test case tests the previous fix for the instantiation of
DeclRefExprs. Note that the "instantiated from" diagnostics still
don't tell us which template arguments we're instantiating with.

llvm-svn: 74540

"semantic analysis" part. Use the "semantic analysis" part when
performing template instantiation on a DeclRefExpr, rather than an ad
hoc list of rules to construct DeclRefExprs from the instantiation.

A test case for this change will come in with a large commit, which
illustrates what I was actually trying to work on.

llvm-svn: 74528

Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.

llvm-svn: 74506

Timings showed no significant difference before and after the commit.

llvm-svn: 74504

redundant, implicit instantiations of function templates and provide a
place where we can hang function template specializations.

llvm-svn: 74454

For a FunctionDecl that has been instantiated due to template argument
deduction, we now store the primary template from which it was
instantiated and the deduced template arguments. From this
information, we can instantiate the body of the function template.

llvm-svn: 74232

templates.

For example, this now type-checks (but does not instantiate the body
of deref<int>):

  template<typename T> T& deref(T* t) { return *t; }

  void test(int *ip) {
    int &ir = deref(ip);
  }

Specific changes/additions:
  * Template argument deduction from a call to a function template.
  * Instantiation of a function template specializations (just the
  declarations) from the template arguments deduced from a call.
  * FunctionTemplateDecls are stored directly in declaration contexts
  and found via name lookup (all forms), rather than finding the
  FunctionDecl and then realizing it is a template. This is
  responsible for most of the churn, since some of the core
  declaration matching and lookup code assumes that all functions are
  FunctionDecls.

llvm-svn: 74213

specialization. At present, all implicit instantiations occur at the
end of the translation unit.

llvm-svn: 73915

compilation, and (hopefully) introduce RAII objects for changing the
"potentially evaluated" state at all of the necessary places within
Sema and Parser. Other changes:

  - Set the unevaluated/potentially-evaluated context appropriately
    during template instantiation.
  - We now recognize three different states while parsing or
    instantiating expressions: unevaluated, potentially evaluated, and
    potentially potentially evaluated (for C++'s typeid).
  - When we're in a potentially potentially-evaluated context, queue
    up MarkDeclarationReferenced calls in a stack. For C++ typeid
    expressions that are potentially evaluated, we will play back
    these MarkDeclarationReferenced calls when we exit the
    corresponding potentially potentially-evaluated context.
  - Non-type template arguments are now parsed as constant
    expressions, so they are not potentially-evaluated.

llvm-svn: 73899

template instantiation. This helps reduce our stack footprint when
performing deep template instantiations.

llvm-svn: 72582

instantiation of tags local to member functions of class templates
(and, eventually, function templates) works when the tag is defined as
part of the decl-specifier-seq, e.g.,

  struct S { T x, y; } s1;

Also, make sure that we don't try to default-initialize a dependent
type.

llvm-svn: 72568

given DeclContext is dependent on type parameters. Use this to
properly determine whether a TagDecl is dependent; previously, we were
missing the case where the TagDecl is a local class of a member
function of a class template (phew!).

Also, make sure that, when we instantiate declarations within a member
function of a class template (or a function template, eventually),
that we add those declarations to the "instantiated locals" map so
that they can be found when instantiating declaration references.

Unfortunately, I was not able to write a useful test for this change,
although the assert() that fires when uncommenting the FIXME'd line in
test/SemaTemplate/instantiate-declref.cpp tells the "experienced user"
that we're now doing the right thing.

llvm-svn: 72526

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

within a template now have a link back to the enumeration from which
they were instantiated. This means that we can now find the
instantiation of an anonymous enumeration.

llvm-svn: 72482

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

llvm-svn: 72210

llvm-svn: 72035

template, introduce that member function into the template
instantiation stack. Also, add diagnostics showing the member function
within the instantiation stack and clean up the qualified-name
printing so that we get something like:

  note: in instantiation of member function 'Switch1<int, 2, 2>::f'
  requested here

in the template instantiation backtrace.

llvm-svn: 72015

llvm-svn: 71936

llvm-svn: 71930

constructors and destructors. This is a requirement of
DeclarationNameTable::getCXXSpecialName that we weren't assert()'ing,
so it should have been caught much earlier :(

Big thanks to Anders for the test case.

llvm-svn: 71895

instantiating the definition of a function from a template.

llvm-svn: 71869

llvm-svn: 71818

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

llvm-svn: 71814