| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 127119
|
|
|
|
|
|
|
|
|
|
|
| |
template (not a specialization!), use the "injected" function template
arguments, which correspond to the template parameters of the function
template. This is required when substituting into the default template
parameters of template template parameters within a function template.
Fixes PR9016.
llvm-svn: 127092
|
|
|
|
|
|
| |
capture the template parameters of template template parameters.
llvm-svn: 127012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DeclContext once we've created it. This mirrors what we do for
function parameters, where the parameters start out with
translation-unit context and then are adopted by the appropriate
DeclContext when it is created. Also give template parameters public
access and make sure that they don't show up for the purposes of name
lookup.
Fixes PR9400, a regression introduced by r126920, which implemented
substitution of default template arguments provided in template
template parameters (C++ core issue 150).
How on earth could the DeclContext of a template parameter affect the
handling of default template arguments?
I'm so glad you asked! The link is
Sema::getTemplateInstantiationArgs(), which determines the outer
template argument lists that correspond to a given declaration. When
we're instantiating a default template argument for a template
template parameter within the body of a template definition (not it's
instantiation, per core issue 150), we weren't getting any outer
template arguments because the context of the template template
parameter was the translation unit. Now that the context of the
template template parameter is its owning template, we get the
template arguments from the injected-class-name of the owning
template, so substitution works as it should.
llvm-svn: 127004
|
|
|
|
| |
llvm-svn: 126999
|
|
|
|
| |
llvm-svn: 126996
|
|
|
|
| |
llvm-svn: 126994
|
|
|
|
|
|
|
|
| |
lead to a serious slowdown (4%) on parsing of Cocoa.h. This memory
optimization should be revisited later, when we have time to look at
the generated code.
llvm-svn: 126033
|
|
|
|
| |
llvm-svn: 125754
|
|
|
|
| |
llvm-svn: 125751
|
|
|
|
| |
llvm-svn: 125750
|
|
|
|
|
|
|
| |
Also, reorganize and make very explicit the logic for determining
the value kind and type of a referenced declaration.
llvm-svn: 125150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a pack expansion, e.g., the parameter pack Values in:
template<typename ...Types>
struct Outer {
template<Types ...Values>
struct Inner;
};
This new implementation approach introduces the notion of an
"expanded" non-type template parameter pack, for which we have already
expanded the types of the parameter pack (to, say, "int*, float*",
for Outer<int*, float*>) but have not yet expanded the values. Aside
from creating these expanded non-type template parameter packs, this
patch updates template argument checking and non-type template
parameter pack instantiation to make use of the appropriate types in
the parameter pack.
llvm-svn: 123845
|
|
|
|
|
|
|
| |
number of expansions, when we know it, and propagate that information
through Sema.
llvm-svn: 123493
|
|
|
|
|
|
| |
it will expand to, if known. Propagate this information throughout Sema.
llvm-svn: 123470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expansion, when it is known due to the substitution of an out
parameter pack. This allows us to properly handle substitution into
pack expansions that involve multiple parameter packs at different
template parameter levels, even when this substitution happens one
level at a time (as with partial specializations of member class
templates and the signatures of member function templates).
Note that the diagnostic we provide when there is an arity mismatch
between an outer parameter pack and an inner parameter pack in this
case isn't as clear as the normal diagnostic for an arity
mismatch. However, this doesn't matter because these cases are very,
very rare and (even then) only typically occur in a SFINAE context.
The other kinds of pack expansions (expression, template, etc.) still
need to support optional tracking of the number of expansions, and we
need the moral equivalent of SubstTemplateTypeParmPackType for
substituted argument packs of template template and non-type template
parameters.
llvm-svn: 123448
|
|
|
|
|
|
|
| |
and mark the fields they use as mutable. This allows us to remove a few
const_casts.
llvm-svn: 123314
|
|
|
|
|
|
|
| |
in ASTContext-allocated memory, copying the provided template
arguments. Use this new routine where we can. No functionality change.
llvm-svn: 123289
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for template template argument pack expansions. This allows fun such
as:
template<template<class> class ...> struct apply_impl { /*...*/ };
template<template<class> class ...Metafunctions> struct apply {
typedef typename apply_impl<Metafunctions...>::type type;
};
However, neither template argument deduction nor template
instantiation is implemented for template template argument packs, so
this functionality isn't useful yet.
I'll probably replace the encoding of template template
argument pack expansions in TemplateArgument so that it's harder to
accidentally forget about the expansion. However, this is a step in
the right general direction.
llvm-svn: 122890
|
|
|
|
|
|
|
| |
template<template<class> class ...Metafunctions>
struct apply_to_each;
llvm-svn: 122874
|
|
|
|
|
|
|
| |
non-type template parameter pack, make sure to create a pack expansion
for the corresponding template argument.
llvm-svn: 122799
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
packs, e.g.,
template<typename T, unsigned ...Dims> struct multi_array;
along with semantic analysis support for finding unexpanded non-type
template parameter packs in types, expressions, and so on.
Template instantiation involving non-type template parameter packs
probably doesn't work yet. That'll come soon.
llvm-svn: 122527
|
|
|
|
|
|
|
|
|
| |
template argument corresponding to a template parameter pack is an
argument pack of a pack expansion of that template parameter
pack. Implements C++0x [temp.dep.type]p2 (at least, as much of it as
we can).
llvm-svn: 122498
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
store it on the expression node. Also store an "object kind",
which distinguishes ordinary "addressed" l-values (like
variable references and pointer dereferences) and bitfield,
@property, and vector-component l-values.
Currently we're not using these for much, but I aim to switch
pretty much everything calculating l-valueness over to them.
For now they shouldn't necessarily be trusted.
llvm-svn: 119685
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
abstractions (e.g., TemplateArgumentListBuilder) that were designed to
support variadic templates. Only a few remnants of variadic templates
remain, in the parser (parsing template type parameter packs), AST
(template type parameter pack bits and TemplateArgument::Pack), and
Sema; these are expected to be used in a future implementation of
variadic templates.
But don't get too excited about that happening now.
llvm-svn: 118385
|
|
|
|
|
|
| |
chained PCH.
llvm-svn: 117533
|
|
|
|
|
|
|
| |
not loading the specializations of a class template until some AST
consumer needs them.
llvm-svn: 117498
|
|
|
|
| |
llvm-svn: 113743
|
|
|
|
|
|
|
|
|
|
|
| |
PCH got a severe beating by the boost-using test case reported here: http://llvm.org/PR8099
Fix issues like:
-When PCH reading, make sure Decl's getASTContext() doesn't get called since a Decl in the parent hierarchy may be initializing.
-In ASTDeclReader::VisitFunctionDecl VisitRedeclarable should be called before using FunctionDecl's isCanonicalDecl()
-In ASTDeclReader::VisitRedeclarableTemplateDecl CommonOrPrev must be initialized before anything else.
llvm-svn: 113391
|
|
|
|
|
|
|
|
|
| |
This patch reimplements the find*Specialization family of member
functions of {Class,Function}TemplateDecl in terms of a common
implementation that uses SpecEntryTraits to obtain the most recent
declaration.
llvm-svn: 109869
|
|
|
|
|
|
|
| |
This patch uses the newly added Latest field of CommonBase to provide
a getNextRedeclaration() implementation for RedeclarableTemplateDecl.
llvm-svn: 109756
|
|
|
|
|
|
|
| |
This patch adds a Latest field to RedeclarableTemplateDecl's CommonBase
class which is used to store the latest redeclaration.
llvm-svn: 109755
|
|
|
|
|
|
|
|
|
|
|
| |
This patch refactors much of the common code in ClassTemplateDecl and
FunctionTemplateDecl into a common base class RedeclarableTemplateDecl
together with support functions in a template class RedeclarableTemplate.
The patch also includes similar refactoring for these classes' PCH
reader and writer implementations.
llvm-svn: 109754
|
|
|
|
| |
llvm-svn: 109380
|
|
|
|
|
|
| |
since we aren't going to be calling them ever.
llvm-svn: 109377
|
|
|
|
| |
llvm-svn: 109113
|
|
|
|
|
|
|
|
|
|
|
| |
detail and introduce
FunctionTemplateDecl::findSpecialization.
Redeclarations of specializations will not cause the previous decl to be removed from the set,
the set will keep the canonical decl. findSpecialization will return the most recent redeclaration.
llvm-svn: 108834
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation detail (InsertPos
leaks though) and add methods to its interface for adding/finding specializations.
Simplifies its users a bit and we no longer need to replace specializations in the folding set with
their redeclarations. We just return the most recent redeclarations.
As a bonus, it fixes http://llvm.org/PR7670.
llvm-svn: 108832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(e.g., a call, cast, etc.), immediately adjust the expression's type
to strip cv-qualifiers off of all non-class types (in C++) or all
types (in C). This effectively extends my previous fix for PR7463,
which was restricted to calls, to other kinds of expressions within
similar characteristics. I've audited every use of
getNonReferenceType() in the code base, switching to the newly-renamed
getNonLValueExprType() where necessary.
Big thanks to Eli for pointing out just how incomplete my original fix
for PR7463 actually was. We've been handling cv-qualifiers on rvalues
wrong for a very, very long time. Fixes PR7463.
llvm-svn: 108253
|
|
|
|
|
|
|
| |
a template, be sure to include the template arguments from the
injected-class-name. Fixes PR7587.
llvm-svn: 107895
|
|
|
|
|
|
| |
them for PCH reading.
llvm-svn: 107468
|
|
|
|
| |
llvm-svn: 106995
|
|
|
|
|
|
| |
ClassTemplatePartialSpecializationDecl to allow PCH read/write.
llvm-svn: 106624
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce:
-FunctionDecl::getTemplatedKind() which returns an enum signifying what kind of templated
FunctionDecl it is.
-An overload of FunctionDecl::setFunctionTemplateSpecialization() which accepts arrays of
TemplateArguments and TemplateArgumentLocs
-A constructor to TemplateArgumentList which accepts an array of TemplateArguments.
llvm-svn: 106532
|
|
|
|
|
|
| |
FunctionTemplateDecl.
llvm-svn: 106412
|
|
|
|
| |
llvm-svn: 106392
|
|
|
|
| |
llvm-svn: 106100
|
|
|
|
| |
llvm-svn: 106099
|
|
|
|
| |
llvm-svn: 105880
|
|
|
|
| |
llvm-svn: 105716
|