| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
class templates
llvm-svn: 83063
|
| |
|
|
|
|
|
|
| |
Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our
use of qualifiers and fix a few places that weren't dealing with qualifiers
quite right; many more remain.
llvm-svn: 82705
|
| |
|
|
|
|
|
|
|
|
| |
when we are not instantiating the corresponding "current
instantiation." This happens, e.g., when we are instantiating a
declaration reference that refers into the "current instantiation" but
occurs in a default function argument. The libstdc++ vector default
constructor now instantiates properly.
llvm-svn: 82069
|
| |
|
|
|
|
|
| |
ordering, along with another test case for partial ordering of partial
specializations.
llvm-svn: 81869
|
| |
|
|
|
|
| |
(C++ [temp.class.order]).
llvm-svn: 81866
|
| |
|
|
|
|
|
|
|
| |
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: 81498
|
| |
|
|
| |
llvm-svn: 81346
|
| |
|
|
| |
llvm-svn: 81063
|
| |
|
|
| |
llvm-svn: 81062
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
involve qualified names, e.g., x->Base::f. We now maintain enough
information in the AST to compare the results of the name lookup of
"Base" in the scope of the postfix-expression (determined at template
definition time) and in the type of the object expression.
llvm-svn: 80953
|
| |
|
|
|
|
| |
each of the functions in the overload set
llvm-svn: 80692
|
| |
|
|
| |
llvm-svn: 80434
|
| |
|
|
| |
llvm-svn: 80418
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
MultiLevelTemplateArgumentList. This is a baby step toward
instantiating member templates; no intended functionality change yet.
llvm-svn: 80380
|
| |
|
|
|
|
| |
functions that don't instantiate definitions.
llvm-svn: 80037
|
| |
|
|
|
|
|
| |
that type. Note that we do not produce a diagnostic if the type is
incomplete; rather, we just don't look for conversion functions. Fixes PR4660.
llvm-svn: 79919
|
| |
|
|
|
|
| |
transformation.
llvm-svn: 79519
|
| |
|
|
| |
llvm-svn: 79504
|
| |
|
|
|
|
|
| |
generic tree transformation (also used for recanonicalization) and a
small amount of template-instantiation-specific logic.
llvm-svn: 78645
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
transform, then use the result for template instantiation. The generic
transformation fixes a few issues:
- It copes better with template template parameters and member
templates (when they're implemented).
- The logic used to replace template template parameters with their
arguments is now centralized in TransformDecl, so that it will apply
for other declaration-instantiation steps.
- The error-recovery strategy is normalized now, so that any error
results in a NULL TemplateName.
llvm-svn: 78292
|
| |
|
|
|
|
|
| |
tree transformation. Template instantiation uses this general
transformation rather than implementing its own transformation.
llvm-svn: 78286
|
| |
|
|
|
|
|
|
|
|
| |
general tree transformation. Also, implement template instantiation
for parameter packs.
In addition, introduce logic to enter the appropriate context for
subexpressions that are not potentially evaluated.
llvm-svn: 78114
|
| |
|
|
|
|
|
|
|
| |
transformation template (TreeTransform) that handles the
transformation and reconstruction of AST nodes. Template instantiation
for types is a (relatively small) customization of the generic tree
transformation.
llvm-svn: 78071
|
| |
|
|
|
|
|
|
| |
template partial specialization. Then, use those template arguments
when instantiating members of that class template partial
specialization. Fixes PR4607.
llvm-svn: 77925
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
const T
can be matched with, e.g.,
volatile int [5]
llvm-svn: 76773
|
| |
|
|
|
|
| |
via ASTContext.
llvm-svn: 76758
|
| |
|
|
| |
llvm-svn: 76321
|
| |
|
|
|
|
| |
place.
llvm-svn: 76274
|
| |
|
|
|
|
| |
from Enea Zaffanella!
llvm-svn: 74831
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
are fewer template arguments than there are template parameters for
that function.
llvm-svn: 74578
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
subclasses.
Timings showed no significant difference before and after the commit.
llvm-svn: 74504
|
| |
|
|
|
|
| |
overloaded function decl.
llvm-svn: 74472
|
| |
|
|
|
|
|
|
|
|
| |
of template instantiation, we were dropping cv-qualifiers on the
instantiated type in a few places. This change reshuffles the
type-instantiation code a little bit so that there's a single place
where we add qualifiers to the instantiated type, so that we won't end
up with this same bug in the future.
llvm-svn: 74331
|
| |
|
|
| |
llvm-svn: 74257
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 74099
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 73713
|