| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes
a massive memory leak when using a BumpPtrAllocator in ASTContext.
Added a FIXME, as the Destroy method for TemplateArgumentList isn't getting called.
This means we will instead leak when using the MallocAllocator.
llvm-svn: 104633
|
|
|
|
|
|
|
|
| |
pointers in the ASTContext, so that the folding sets stored inside
them will be deallocated when the ASTContext is destroyed (under
-disable-free). <rdar://problem/7998824>.
llvm-svn: 104465
|
|
|
|
|
|
| |
getFullSourceRange -> getSourceRange for TypeLoc.
llvm-svn: 104220
|
|
|
|
|
|
| |
c++'03 code and variadic support "needs work".
llvm-svn: 104195
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
smallvector
instead of new[]'d. This greatly reduces the number of new[]'s, and guess what,
they were all leaked.
This adds a fixme in this hunk:
unsigned NumPackArgs = NumFlatArgs - PackBeginIndex;
+ // FIXME: NumPackArgs shouldn't be negative here???
if (NumPackArgs)
- PackArgs = &FlatArgs[PackBeginIndex];
+ PackArgs = FlatArgs.data()+PackBeginIndex;
where test/SemaTemplate/variadic-class-template-2.cpp is accessing the vector
out of range and NumPackArgs is negative. I assume variadic template args are
completely hosed.
llvm-svn: 104194
|
|
|
|
|
|
|
| |
be a copy constructor (since it isn't one semantically)
and fix the ownership bits it sets to be correct!
llvm-svn: 104192
|
|
|
|
|
|
|
| |
"structure" arg lists, the first step to fixing some massive
memory leaks.
llvm-svn: 104191
|
|
|
|
|
|
|
|
|
| |
different tag kind ("struct" vs. "class") than the primary template,
which has an affect on access control.
Should fix the last remaining Boost.Accumulors failure.
llvm-svn: 103144
|
|
|
|
|
|
|
|
|
|
|
| |
specializations, which keeps track of the order in which they were
originally declared. We use this number so that we can always walk the
list of partial specializations in a predictable order during matching
or template instantiation. This also fixes a failure in Boost.Proto,
where SourceManager::isBeforeInTranslationUnit was behaving
poorly in inconsistent ways.
llvm-svn: 102693
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of a class template or class template partial specialization. That is to
say, in
template <class T> class A { ... };
or
template <class T> class B<const T*> { ... };
make 'A<T>' and 'B<const T*>' sugar for the corresponding InjectedClassNameType
when written inside the appropriate context. This allows us to track the
current instantiation appropriately even inside AST routines. It also allows
us to compute a DeclContext for a type much more efficiently, at some extra
cost every time we write a template specialization (which can be optimized,
but I've left it simple in this patch).
llvm-svn: 102407
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
injected class name of a class template or class template partial specialization.
This is a non-canonical type; the canonical type is still a template
specialization type. This becomes the TypeForDecl of the pattern declaration,
which cleans up some amount of code (and complicates some other parts, but
whatever).
Fixes PR6326 and probably a few others, primarily by re-establishing a few
invariants about TypeLoc sizes.
llvm-svn: 98134
|
|
|
|
|
|
| |
when implicitly supplied to the injected class name.
llvm-svn: 94948
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variables,
but the results are imperfect.
For posterity, I did:
cat <<EOF > $cmdfile
s/DeclaratorInfo/TypeSourceInfo/g
s/DInfo/TInfo/g
s/TypeTypeSourceInfo/TypeSourceInfo/g
s/SourceTypeSourceInfo/TypeSourceInfo/g
EOF
find lib -name '*.cpp' -not -path 'lib/Parse/*' -exec sed -i '' -f $cmdfile '{}' \;
find lib -name '*.h' -exec sed -i '' -f $cmdfile '{}' \;
find include -name '*.h' -not -path 'include/clang/Parse/*' -not -path 'include/clang/Basic/*' -exec sed -i '' -f $cmdfile '{}' \;
llvm-svn: 90743
|