| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
locations" into
a new class. Use it pervasively throughout Sema.
My fingers hurt.
llvm-svn: 89638
|
|
|
|
|
|
| |
definition of a member template (or a member thereof). Fixes PR5566.
llvm-svn: 89512
|
|
|
|
|
|
|
|
| |
appropriate lookup and simply can't resolve the referrent yet, and
"dependent scope" expressions, where we can't do the lookup yet because the
entity we need to look into is a dependent type.
llvm-svn: 89402
|
|
|
|
|
|
|
| |
rather than NamedDecl*. This is a major step towards eliminating
OverloadedFunctionDecl.
llvm-svn: 89263
|
|
|
|
| |
llvm-svn: 89199
|
|
|
|
|
|
|
|
|
|
| |
two classes, one for typenames and one for values; this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard. Track the location of the 'typename' keyword in a using-typename
decl. Make a new lookup result for unresolved values and deal with it in
most places.
llvm-svn: 89184
|
|
|
|
|
|
| |
be complete.
llvm-svn: 89042
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LookupResult RAII powers to diagnose ambiguity in the results. Other diagnostics
(e.g. access control and deprecation) will be moved to automatically trigger
during lookup as part of this same mechanism.
This abstraction makes it much easier to encapsulate aliasing declarations
(e.g. using declarations) inside the lookup system: eventually, lookup will
just produce the aliases in the LookupResult, and the standard access methods
will naturally strip the aliases off.
llvm-svn: 89027
|
|
|
|
|
|
|
|
|
| |
non-type template parameters or constants of pointer-to-member
type. Once checked, be sure to retain those pointer-to-member
constants as expressions if they are dependent, or as declarations if
they are not dependent.
llvm-svn: 87010
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Comparing template parameter lists to determine if we have a redeclaration
- Comparing template parameter lists to determine if we have equivalent
template template parameters
- Comparing template parameter lists to determine whether a template
template argument is valid for a given template template parameter.
Previously, we did not distinguish between the last two cases, which
got us into trouble when we were looking for exact type matches
between the types of non-type template parameters that were dependent
types. Now we do, so we properly delay checking of template template
arguments until instantiation time.
Also, fix an accidental fall-through in a case statement that was
causing crashes.
llvm-svn: 86992
|
|
|
|
|
|
|
|
|
|
| |
template template parameter.
When building a template-id type, check whether the template-name
itself is dependent (even if the template arguments are not!) and
handle it as a template-id type.
llvm-svn: 86913
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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-type-parameter specific template argument checking code and
up to the template argument checking loop. In theory, this should make
variadic templates work better; in practice, they don't well enough
for us to care anyway (YET!), so this is mostly a re-organization to
simplify CheckTemplateArgument.
llvm-svn: 86868
|
|
|
|
|
|
| |
increase sanity. No intended functionality change.
llvm-svn: 86866
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handling template template parameters properly. This refactoring:
- Parses template template arguments as id-expressions, representing
the result of the parse as a template name (Action::TemplateTy)
rather than as an expression (lame!).
- Represents all parsed template arguments via a new parser-specific
type, ParsedTemplateArgument, which stores the kind of template
argument (type, non-type, template) along with all of the source
information about the template argument. This replaces an ad hoc
set of 3 vectors (one for a void*, which was either a type or an
expression; one for a bit telling whether the first was a type or
an expression; and one for a single source location pointing at
the template argument).
- Moves TemplateIdAnnotation into the new Parse/Template.h. It never
belonged in the Basic library anyway.
llvm-svn: 86708
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Fixes PR5349.
llvm-svn: 86052
|
|
|
|
|
|
|
|
| |
overloaded operators, e.g.,
p->template operator+<T>()
llvm-svn: 85989
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
"->" with a use of ParseUnqualifiedId. Collapse
ActOnMemberReferenceExpr, ActOnDestructorReferenceExpr (both of them),
ActOnOverloadedOperatorReferenceExpr,
ActOnConversionOperatorReferenceExpr, and
ActOnMemberTemplateIdReferenceExpr into a single, new action
ActOnMemberAccessExpr that does the same thing more cleanly (and can
keep more source-location information).
llvm-svn: 85930
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
match it up with a declaration in the outer scope.
llvm-svn: 85628
|
|
|
|
|
|
|
|
| |
declaration.
Provide an API for getting the SourceRange of a TAL and use it judiciously.
llvm-svn: 85520
|
|
|
|
|
|
|
| |
types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.
llvm-svn: 85500
|
|
|
|
|
|
|
|
| |
class template partial specializations of member templates. Also,
fixes a silly little bug in the marking of "used" template parameters
in member templates. Fixes PR5236.
llvm-svn: 85447
|
|
|
|
|
|
|
|
|
| |
members that have a definition. Also, use
CheckSpecializationInstantiationRedecl as part of this instantiation
to make sure that we diagnose the various kinds of problems that can
occur with explicit instantiations.
llvm-svn: 85270
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qualified reference to a declaration that is not a non-static data
member or non-static member function, e.g.,
namespace N { int i; }
int j = N::i;
Instead, extend DeclRefExpr to optionally store the qualifier. Most
clients won't see or care about the difference (since
QualifierDeclRefExpr inherited DeclRefExpr). However, this reduces the
number of top-level expression types that clients need to cope with,
brings the implementation of DeclRefExpr into line with MemberExpr,
and simplifies and unifies our handling of declaration references.
Extended DeclRefExpr to (optionally) store explicitly-specified
template arguments. This occurs when naming a declaration via a
template-id (which will be stored in a TemplateIdRefExpr) that,
following template argument deduction and (possibly) overload
resolution, is replaced with a DeclRefExpr that refers to a template
specialization but maintains the template arguments as written.
llvm-svn: 84962
|
|
|
|
|
|
|
|
|
|
|
| |
N::f<int>
keep track of the full nested-name-specifier. This is mainly QoI and
relatively hard to test; will try to come up with a printing-based
test once we also retain the explicit template arguments past overload
resolution.
llvm-svn: 84869
|
|
|
|
|
|
| |
into an (implicit) member access expression. Fixes PR5220
llvm-svn: 84848
|
|
|
|
|
|
| |
Substitute TemplateIdRefExprs with DeclRefExprs. Doug, plz review :)
llvm-svn: 84763
|
|
|
|
|
|
| |
QualTypes. Don't actually exploit this yet.
llvm-svn: 84716
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to all callers. Switch a few other users of CK_Unknown to proper cast
kinds.
Note that there are still some situations where we end up with
CK_Unknown; they're pretty easy to find with grep. There
are still a few missing conversion kinds, specifically
pointer/int/float->bool and the various combinations of real/complex
float/int->real/complex float/int.
llvm-svn: 84623
|
|
|
|
|
|
|
|
|
| |
CheckSpecializationInstantiationRedecl to check for
redeclarations/instantiations. Also fixes a longstanding issue where
our explicit-instantiation location information wasn't as good as it
could have been.
llvm-svn: 84216
|
|
|
|
| |
llvm-svn: 84189
|
|
|
|
|
|
|
|
|
| |
instantiation redeclaration semantics for function template
specializations and member functions of class template
specializations. Also, record the point of instantiation for
explicit-instantiated functions and static data members.
llvm-svn: 84188
|
|
|
|
|
|
|
|
| |
specializations. Work in progress; there's more cleanup required to
actually use the new CheckSpecializationInstantiationRedecl checker
uniformly.
llvm-svn: 84185
|
|
|
|
|
|
|
|
| |
functions/static data members of class template specializations that
do not have definitions. This is the latter part of [temp.explicit]p4;
the former part still needs more testing.
llvm-svn: 84182
|
|
|
|
|
|
|
|
| |
cases where an explicit instantiation requires a definition; the
remainder of these checks will come with the implementation of
paragraph 4 of [temp.explicit].
llvm-svn: 84181
|
|
|
|
|
|
|
| |
instantiations, since the requirements are too different from those
for template specializations. Simplify it slightly.
llvm-svn: 84156
|
|
|
|
|
|
|
| |
focusing on the scope- and qualifier-related semantic requirements in
C++ [temp.explicit]p2.
llvm-svn: 84154
|
|
|
|
| |
llvm-svn: 84148
|
|
|
|
| |
llvm-svn: 84129
|
|
|
|
|
|
|
|
| |
template, make sure to get the template that corresponds to *this*
declaration of the class template or specialization, rather than the
canonical specialization. Fixes PR5187.
llvm-svn: 84119
|
|
|
|
|
|
|
|
|
|
| |
what we found when we looked into <blah>", where <blah> is a
DeclContext*. We can now format DeclContext*'s in nice ways, e.g.,
"namespace N", "the global namespace", "'class Foo'".
This is part of PR3990, but we're not quite there yet.
llvm-svn: 84028
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template as a specialization. For example, this occurs with:
template<typename T>
struct X {
template<typename U> struct Inner { /* ... */ };
};
template<> template<typename T>
struct X<int>::Inner {
T member;
};
We need to treat templates that are member specializations as special
in two contexts:
- When looking for a definition of a member template, we look
through the instantiation chain until we hit the primary template
*or a member specialization*. This allows us to distinguish
between the primary "Inner" definition and the X<int>::Inner
definition, above.
- When computing all of the levels of template arguments needed to
instantiate a member template, don't add template arguments
from contexts outside of the instantiation of a member
specialization, since the user has already manually substituted
those arguments.
Fix up the existing test for p18, which was actually wrong (but we
didn't diagnose it because of our poor handling of member
specializations of templates), and add a new test for member
specializations of templates.
llvm-svn: 83974
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function templates.
This commit ensures that friend function templates are constructed as
FunctionTemplateDecls rather than partial FunctionDecls (as they
previously were). It then implements template instantiation for friend
function templates, injecting the friend function template only when
no previous declaration exists at the time of instantiation.
Oh, and make sure that explicit specialization declarations are not
friends.
llvm-svn: 83970
|