| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
that the scope in which it is being declared is complete. Also, when
instantiating a member class template's ClassTemplateDecl, be sure to
delay type creation so that the resulting type is dependent. Ick.
llvm-svn: 83923
|
|
|
|
|
|
|
| |
instantiation has already been required. To do so, keep track of the
point of instantiation for anything that can be instantiated.
llvm-svn: 83890
|
|
|
|
|
|
|
| |
Split the various ambiguous result enumerators into their own enum. Tests
for most of C++ [namespace.qual].
llvm-svn: 83700
|
|
|
|
|
|
|
|
|
| |
users to
pass a LookupResult reference to lookup routines. Call out uses which assume a single
result.
llvm-svn: 83674
|
|
|
|
|
|
|
|
| |
injected-class-name (e.g., when we're referring to other
specializations of the current class template). Make sure that we see
the template rather than the injected-class-name. Fixes PR4768.
llvm-svn: 83672
|
|
|
|
|
|
|
|
|
|
|
| |
templates, and keep track of how those member classes were
instantiated or specialized.
Make sure that we don't try to instantiate an explicitly-specialized
member class of a class template, when that explicit specialization
was a declaration rather than a definition.
llvm-svn: 83547
|
|
|
|
|
|
|
|
| |
track of the kind of specialization or instantiation. Also, check the
scope of the specialization and ensure that a specialization
declaration without an initializer is not a definition.
llvm-svn: 83533
|
|
|
|
|
|
|
| |
template instantiation of a member function of a class template.
FIXME -= 2;
llvm-svn: 83520
|
|
|
|
|
|
|
|
|
| |
function of a class template was implicitly instantiated, explicitly
instantiated (declaration or definition), or explicitly
specialized. The same MemberSpecializationInfo structure will be used
for static data members and member classes as well.
llvm-svn: 83509
|
|
|
|
|
|
|
|
| |
templates. Previously, these weren't handled as specializations at
all. The AST for representing these as specializations is still a work
in progress.
llvm-svn: 83498
|
|
|
|
| |
llvm-svn: 83473
|
|
|
|
|
|
|
|
|
|
| |
its definition may be defined, including in a class.
Also, put in an assertion when trying to instantiate a class template
partial specialization of a member template, which is not yet
implemented.
llvm-svn: 83469
|
|
|
|
|
|
|
|
|
| |
declarations and explicit template instantiations, improving
diagnostics and making the code usable for function template
specializations (as well as class template specializations and partial
specializations).
llvm-svn: 83436
|
|
|
|
|
|
|
| |
explicit specializations can occur. Also, fix a minor recovery bug
where we should allow declarations coming from the parser to be NULL.
llvm-svn: 83416
|
|
|
|
|
|
|
| |
explicit instantiation. Also, tighten up reference-count checking to
help catch these issues earlier. Fixes PR5069.
llvm-svn: 83225
|
|
|
|
|
|
|
|
|
|
|
|
| |
specializations such as:
friend class std::vector<int>;
by using the same code path as explicit specializations, customized to
reference an existing ClassTemplateSpecializationDecl (or build a new
"undeclared" one).
llvm-svn: 82875
|
|
|
|
|
|
|
| |
scope *up to and including* the innermost namespace scope, rather than
just searching in the innermost namespace scope.
llvm-svn: 82849
|
|
|
|
|
|
|
|
|
| |
class templates. We now treat friend class templates much more like
normal class templates, except that they still get special name lookup
rules. Fixes PR5057 and eliminates a bunch of spurious diagnostics in
<iostream>.
llvm-svn: 82848
|
|
|
|
|
|
| |
most-specialized function template
llvm-svn: 82840
|
|
|
|
|
|
| |
explicit template specializations, when available.
llvm-svn: 82824
|
|
|
|
|
|
|
|
|
|
|
| |
template void f<int>(int);
~~~~~~
Previously, we silently dropped the template arguments. With this
change, we now use the template arguments (when available) as the
explicitly-specified template arguments used to aid template argument
deduction for explicit template instantiations.
llvm-svn: 82806
|
|
|
|
|
|
|
|
| |
member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.
llvm-svn: 82789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
first implementation recognizes when a function declaration is an
explicit function template specialization (based on the presence of a
template<> header), performs template argument deduction + ambiguity
resolution to determine which template is being specialized, and hooks
There are many caveats here:
- We completely and totally drop any explicitly-specified template
arguments on the floor
- We don't diagnose any of the extra semantic things that we should
diagnose.
- I haven't looked to see that we're getting the right linkage for
explicit specializations
On a happy note, this silences a bunch of errors that show up in
libstdc++'s <iostream>, although Clang still can't get through the
entire header.
llvm-svn: 82728
|
|
|
|
|
|
|
|
|
|
|
| |
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
|
|
|
|
| |
llvm-svn: 81960
|
|
|
|
|
|
| |
(C++ [temp.class.order]).
llvm-svn: 81866
|
|
|
|
| |
llvm-svn: 81801
|
|
|
|
|
|
|
|
| |
MarkUsedTemplateParameters, which is able to mark template parameters
used within non-deduced contexts as well as deduced contexts. Use this
to finish the implementation of [temp.deduct.partial]p11.
llvm-svn: 81794
|
|
|
|
|
|
|
|
|
| |
instantiation definition can follow an explicit instantiation
declaration. This is as far as I want to go with extern templates now,
but they will still need quite a bit more work to get all of the C++0x
semantics right.
llvm-svn: 81573
|
|
|
|
|
|
|
|
|
|
| |
from its location. Initialize appropriately.
When implicitly creating a declaration of a class template specialization
after encountering the first reference to it, use the pattern class's
location instead of the location of the first reference.
llvm-svn: 81515
|
|
|
|
| |
llvm-svn: 81504
|
|
|
|
| |
llvm-svn: 81346
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates, e.g.,
x.template get<T>
We can now parse these, represent them within an UnresolvedMemberExpr
expression, then instantiate that expression node in simple cases.
This allows us to stumble through parsing LLVM's Casting.h.
llvm-svn: 81300
|
|
|
|
| |
llvm-svn: 81233
|
|
|
|
|
|
|
|
|
|
|
| |
templates. We now distinguish between an explicit instantiation
declaration and an explicit instantiation definition, and know not to
instantiate explicit instantiation declarations. Unfortunately, there
is some remaining confusion w.r.t. instantiation of out-of-line member
function definitions that causes trouble here.
llvm-svn: 81053
|
|
|
|
|
|
| |
then drop it on the floor.
llvm-svn: 80989
|
|
|
|
|
|
| |
friends.
llvm-svn: 80977
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x->Base::f
We no longer try to "enter" the context of the type that "x" points
to. Instead, we drag that object type through the parser and pass it
into the Sema routines that need to know how to perform lookup within
member access expressions.
We now implement most of the crazy name lookup rules in C++
[basic.lookup.classref] for non-templated code, including performing
lookup both in the context of the type referred to by the member
access and in the scope of the member access itself and then detecting
ambiguities when the two lookups collide (p1 and p4; p3 and p7 are
still TODO). This change also corrects our handling of name lookup
within template arguments of template-ids inside the
nested-name-specifier (p6; we used to look into the scope of the
object expression for them) and fixes PR4703.
I have disabled some tests that involve member access expressions
where the object expression has dependent type, because we don't yet
have the ability to describe dependent nested-name-specifiers starting
with an identifier.
llvm-svn: 80843
|
|
|
|
| |
llvm-svn: 80785
|
|
|
|
|
|
|
|
|
|
|
|
| |
simple-template-id form), check whether the scope specifier is
computable as a declaration context rather than checking whether it is
dependent, so that we properly cope with members of the current
instantiation.
Improve testing for typename specifiers that terminate in a
simpe-template-id.
llvm-svn: 80783
|
|
|
|
|
|
|
|
|
| |
explicitly-specified template argument lists in member reference
expressions, e.g.,
x->f<int>()
llvm-svn: 80646
|
|
|
|
|
|
| |
member templates.
llvm-svn: 80396
|
|
|
|
|
|
|
|
|
|
| |
to a multi-level template argument list by making it explicit. The
forced auditing of callers found a bug in the instantiation of member
classes inside member templates.
I *love* static type systems.
llvm-svn: 80391
|
|
|
|
|
|
|
|
|
|
| |
When performing template instantiation of the definitions of member
templates (or members thereof), we build a data structure containing
the template arguments from each "level" of template
instantiation. During template instantiation, we substitute all levels
of template arguments simultaneously.
llvm-svn: 80389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
their members, including member class template, member function
templates, and member classes and functions of member templates.
To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,
template<typename X> template<typename Y>
X Outer<X>::Inner1<Y>::foo(Y) {
return X();
}
we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.
Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.
llvm-svn: 80044
|
|
|
|
|
|
| |
functions that don't instantiate definitions.
llvm-svn: 80037
|
|
|
|
|
|
|
|
|
| |
the logic is there for out-of-line definitions with multiple levels of
nested templates, but this is still a work-in-progress: we're having
trouble determining when we should look into a dependent
nested-name-specifier.
llvm-svn: 80003
|
|
|
|
| |
llvm-svn: 79395
|
|
|
|
|
|
|
|
|
|
|
|
| |
interfaces.
DeclaratorDecl contains a DeclaratorInfo* to keep type source info.
Subclasses of DeclaratorDecl are FieldDecl, FunctionDecl, and VarDecl.
EnumConstantDecl still inherits from ValueDecl since it has no need for DeclaratorInfo.
Decl/Sema interfaces accept a DeclaratorInfo as parameter but no DeclaratorInfo is created yet.
llvm-svn: 79392
|
|
|
|
| |
llvm-svn: 78735
|