| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
DeclRefExprs
llvm-svn: 89649
|
|
|
|
|
|
|
|
|
|
| |
locations" into
a new class. Use it pervasively throughout Sema.
My fingers hurt.
llvm-svn: 89638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
classes. Move its implementation into a new module.
This will seem marginally more justified in a bit.
llvm-svn: 85499
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 84973
|
|
|
|
| |
llvm-svn: 84891
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
same.
llvm-svn: 82088
|
|
|
|
|
|
| |
(C++ [temp.class.order]).
llvm-svn: 81866
|
|
|
|
|
|
| |
specialization types differently.
llvm-svn: 81512
|
|
|
|
| |
llvm-svn: 81346
|
|
|
|
|
|
| |
DeclaratorInfo to get this information.
llvm-svn: 79584
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
template partial specialization. Then, use those template arguments
when instantiating members of that class template partial
specialization. Fixes PR4607.
llvm-svn: 77925
|
|
|
|
|
|
| |
partial specializations.
llvm-svn: 77606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Allow the Index library (and any other interested client) to walk
the set of declarations for a given tag (enum, union, class,
whatever). At the moment, this information is not readily available.
2) Reduce our dependence on TagDecl::TypeForDecl being mapped down
to a TagType (for which getDecl() will return the tag definition, if
one exists). This property won't exist for class template partial
specializations.
3) Make the canonical declaration of a TagDecl actually canonical,
e.g., so that it does not change when the tag is defined.
llvm-svn: 77523
|
|
|
|
|
|
|
|
| |
canonicalization for dependent TemplateSpecializationTypes occurs
within ASTContext::getTemplateSpecializationType. Also, move template
argument canonicalization into ASTContext::getCanonicalTemplateArgument.
llvm-svn: 77388
|
|
|
|
|
|
| |
place.
llvm-svn: 76274
|
|
|
|
|
|
| |
method Decl::getCanonicalDecl().
llvm-svn: 76273
|
|
|
|
|
|
|
| |
redundant, implicit instantiations of function templates and provide a
place where we can hang function template specializations.
llvm-svn: 74454
|
|
|
|
|
|
| |
variadic templates.
llvm-svn: 73937
|
|
|
|
| |
llvm-svn: 73452
|
|
|
|
| |
llvm-svn: 73395
|
|
|
|
| |
llvm-svn: 73391
|
|
|
|
| |
llvm-svn: 73281
|
|
|
|
|
|
| |
parameter packs.
llvm-svn: 73272
|
|
|
|
| |
llvm-svn: 73261
|
|
|
|
| |
llvm-svn: 72976
|
|
|
|
|
|
| |
going to need it later). Move push_back to the .cpp file. If the passed in template argument is a type, assert that it's canonical.
llvm-svn: 72918
|
|
|
|
| |
llvm-svn: 72917
|
|
|
|
| |
llvm-svn: 72916
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
we have the basics of declaring and storing class template partial
specializations, matching class template partial specializations at
instantiation time via (limited) template argument deduction, and
using the class template partial specialization's pattern for
instantiation.
This patch is enough to make a simple is_pointer type trait work, but
not much else.
llvm-svn: 72662
|
|
|
|
|
|
|
|
| |
TemplateArgumentList. This avoids the need to pass around
pointer/length pairs of template arguments lists, and will eventually
make it easier to introduce member templates and variadic templates.
llvm-svn: 71517
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template. The injected-class-name is either a type or a template,
depending on whether a '<' follows it. As a type, the
injected-class-name's template argument list contains its template
parameters in declaration order.
As part of this, add logic for canonicalizing declarations, and be
sure to canonicalize declarations used in template names and template
arguments.
A TagType is dependent if the declaration it references is dependent.
I'm not happy about the rather complicated protocol needed to use
ASTContext::getTemplateSpecializationType.
llvm-svn: 71408
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dependent qualified-ids such as
Fibonacci<N - 1>::value
where N is a template parameter. These references are "unresolved"
because the name is dependent and, therefore, cannot be resolved to a
declaration node (as we would do for a DeclRefExpr or
QualifiedDeclRefExpr). UnresolvedDeclRefExprs instantiate to
DeclRefExprs, QualifiedDeclRefExprs, etc.
Also, be a bit more careful about keeping only a single set of
specializations for a class template, and instantiating from the
definition of that template rather than a previous declaration. In
general, we need a better solution for this for all TagDecls, because
it's too easy to accidentally look at a declaration that isn't the
definition.
We can now process a simple Fibonacci computation described as a
template metaprogram.
llvm-svn: 67308
|