annotation token, because some of the tokens we're annotating might
not be in the set of cached tokens (we could have consumed them
unconditionally).
Also, move the tentative parsing from ParseTemplateTemplateArgument
into the one caller that needs it, improving recovery.
llvm-svn: 86904
permits, among other things, ripping apart and reconstructing
templates via partial specialization:
template<typename T>
struct DeepRemoveConst { typedef T type; };
template<typename T>
struct DeepRemoveConst<const T> {
typedef typename DeepRemoveConst<T>::type type;
};
template<template<typename> class TT, typename T>
struct DeepRemoveConst<TT<T> > {
typedef TT<typename DeepRemoveConst<T>::type> type;
};
Also, fix a longstanding thinko in the code handling partial ordering
of class template partial specializations. We were performing the
second deduction without clearing out the results of the first
deduction. It's amazing we got through so much code with such a
horrendous error :(
llvm-svn: 86893
with its corresponding template parameter. This can happen when we
performed some substitution into the default template argument and
what we had doesn't match any more, e.g.,
template<int> struct A;
template<typename T, template<T> class X = A> class B;
B<long> b;
Previously, we'd emit a pretty but disembodied diagnostic showing how
the default argument didn't match the template parameter. The
diagnostic was good, but nothing tied it to the *use* of the default
argument in "B<long>". This commit fixes that.
Also, tweak the counting of active template instantiations to avoid
counting non-instantiation records, such as those we create for
(surprise!) checking default arguments, instantiating default
arguments, and performing substitutions as part of template argument
deduction.
llvm-svn: 86884
template template parameter, substitute any prior template arguments
into the template template parameter. This, for example, allows us to
properly check the template template argument for a class such as:
template<typename T, template<T Value> class X> struct Foo;
The actual implementation of this feature was trivial; most of the
change is dedicated to giving decent diagnostics when this
substitution goes horribly wrong. We now get a note like:
note: while substituting prior template arguments into template
template parameter 'X' [with T = float]
As part of this change, enabled some very pedantic checking when
comparing template template parameter lists, which shook out a bug in
our overly-eager checking of default arguments of template template
parameters. We now perform only minimal checking of such default
arguments when they are initially parsed.
llvm-svn: 86864
nested-name-specifiers so that they don't gobble the template name (or
operator-function-id) unless there is also a
template-argument-list. For example, given
T::template apply
we would previously consume both "template" and "apply" as part of
parsing the nested-name-specifier, then error when we see that there
is no "<" starting a template argument list. Now, we parse such
constructs tentatively, and back off if the "<" is not present. This
allows us to parse dependent template names as one would use them for,
e.g., template template parameters:
template<typename T, template<class> class X = T::template apply>
struct MetaSomething;
Also, test default arguments for template template parameters.
llvm-svn: 86841
parameters. Rather than storing them as either declarations (for the
non-dependent case) or expressions (for the dependent case), we now
(always) store them as TemplateNames.
The primary change here is to add a new kind of TemplateArgument,
which stores a TemplateName. However, making that change ripples to
every switch on a TemplateArgument's kind, also affecting
TemplateArgumentLocInfo/TemplateArgumentLoc, default template
arguments for template template parameters, type-checking of template
template arguments, etc.
This change is light on testing. It should fix several pre-existing
problems with template template parameters, such as:
- the inability to use dependent template names as template template
arguments
- template template parameter default arguments cannot be
instantiation
However, there are enough pieces missing that more implementation is
required before we can adequately test template template parameters.
llvm-svn: 86777
templates. The instantiation of these default arguments must be (and
now, is) delayed until the template argument is actually used, at
which point we substitute all levels of template arguments
concurrently.
llvm-svn: 86578
(without complaining if it fails) to get proper semantics: reference
binding with a derived-to-base conversion and the enumeration of
constructors for user-defined conversions. There are probably more
cases to fix, but my prior attempt at statically ensuring that
complete-type checking always happens failed. Perhaps I'll try again.
With this change, Clang can parse include/llvm/*.h!
llvm-svn: 86129
still be dependent or invoke an overloaded operator. Previously, we
only supported builtin operators.
BinaryOperator/CompoundAssignOperator didn't have this issue because
we always built a CXXOperatorCallExpr node, even when name lookup
didn't find any functions to save until instantiation time. Now, that
code builds a BinaryOperator or CompoundAssignOperator rather than a
CXXOperatorCallExpr, to save some space.
llvm-svn: 86087
type of the object even when it is dependent. Specifically, this makes
sure that we get the right type for "this->", which is important when
performing name lookup into this scope to determine whether an
identifier or operator-function-id is a template name.
llvm-svn: 86060
expressions, keep track of whether we are immediately taking the
address of the expression. Pass this flag when building a declaration
name expression so that we handle pointer-to-member constants
properly.
llvm-svn: 86017
operators, e.g.,
operator+<int>
which now works in declarators, id-expressions, and member access
expressions. This commit only implements the non-dependent case, where
we can resolve the template-id to an actual declaration.
llvm-svn: 85966
representation of a C++ unqualified-id, along with a single parsing
function (Parser::ParseUnqualifiedId) that will parse all of the
various forms of unqualified-id in C++.
Replace the representation of the declarator name in Declarator with
the new UnqualifiedId class, simplifying declarator-id parsing
considerably and providing more source-location information to
Sema. In the future, I hope to migrate all of the other
unqualified-id-parsing code over to this single representation, then
begin to merge actions that are currently only different because we
didn't have a unqualified notion of the name in the parser.
llvm-svn: 85851
integral constant expression, make sure to find where the initializer
was provided---inside or outside the class definition---since that can
affect whether we have an integral constant expression (and, we need
to see the initializer itself).
llvm-svn: 85741
that is not known to be a base class at template definition time due
to some dependent base class. Treat qualified name lookup that refers
to a non-static data member or function as implicit class member
access when the "this" type would be dependent.
llvm-svn: 85718
parameters and template type parameters, which occurs when
substituting into the declarations of member templates inside class
templates. This eliminates errors about our inability to "reduce
non-type template parameter depth", fixing PR5311.
Also fixes a bug when instantiating a template type parameter
declaration in a member template, where we weren't properly reducing
the template parameter's depth.
LLVM's StringSwitch header now parses.
llvm-svn: 85669
instantiation once we have committed to performing the
instantiation. As part of this, make our makeshift
template-instantiation location information suck slightly less.
Fixes PR5264.
llvm-svn: 85209
so that we maintain better source information after template argument
deduction and overloading resolves down to a specific
declaration. Found and dealt with a few more cases that
FixOverloadedFunctionReference didn't cope with.
(Finally) added a test case that puts together this change with the
DeclRefExpr change to (optionally) include nested-name-specifiers and
explicit template argument lists.
llvm-svn: 84974
Douglas Gregor