visible.
The basic problem here is that a given translation unit can use
forward declarations to form pointers to a given type, say,
class X;
X *x;
and then import a module that includes a definition of X:
import XDef;
We will then fail when attempting to access a member of X, e.g.,
x->method()
because the AST reader did not know to look for a default of a class
named X within the new module.
This implementation is a bit of a C-centric hack, because the only
definitions that can have this property are enums, structs, unions,
Objective-C classes, and Objective-C protocols, and all of those are
either visible at the top-level or can't be defined later. Hence, we
can use the out-of-date-ness of the name and the identifier-update
mechanism to force the update.
In C++, we will not be so lucky, and will need a more advanced
solution, because the definitions could be in namespaces defined in
two different modules, e.g.,
// module 1
namespace N { struct X; }
// module 2
namespace N { struct X { /* ... */ }; }
One possible implementation here is for C++ to extend the information
associated with each identifier table to include the declaration IDs
of any definitions associated with that name, regardless of
context. We would have to eagerly load those definitions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174794 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
unexpanded parameter pack is a pack expansion. Thus, as with a non-type template
parameter which is a pack expansion, it needs to be expanded early into a fixed
list of template parameters.
Since the expanded list of template parameters is not itself a parameter pack,
it is permitted to appear before the end of the template parameter list, so also
remove that restriction (for both template template parameter pack expansions and
non-type template parameter pack expansions).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163369 91177308-0d34-0410-b5e6-96231b3b80d8
of templates by using the newly introduce FoldingSetVector. This
preserves insertion order for all iteration of specializations.
I've also included a somewhat terrifying testcase that rapidly builds up
a large number of functions. This is enough that any system with ASLR
will have non-deterministic debug information generated for the test
case without the fix here as the debug information is generated in part
by walking these specializations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156133 91177308-0d34-0410-b5e6-96231b3b80d8
search for the specialization (in a folding set) and, if not found
form a *Decl that is then inserted into that folding set. In rare
cases, the folding set may be reallocated between the search and the
insertion, causing a crash. No test case, because triggering rehashing
consistently in a small test case is not feasible. Fixes
<rdar://problem/11115071>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153575 91177308-0d34-0410-b5e6-96231b3b80d8
track whether the referenced declaration comes from an enclosing
local context. I'm amenable to suggestions about the exact meaning
of this bit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152491 91177308-0d34-0410-b5e6-96231b3b80d8
we have a redeclarable type, and only use the new virtual versions
(getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have
that type information. This keeps us from penalizing users with strict
type information (and is the moral equivalent of a "final" method).
Plus, settle on the names getPreviousDecl() and getMostRecentDecl()
throughout.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148187 91177308-0d34-0410-b5e6-96231b3b80d8
Redeclarable<RedeclarableTemplateDecl>, eliminating a bunch of
redeclaration-chain logic both in RedeclarableTemplateDecl and
especially in its (de-)serialization.
As part of this, eliminate the RedeclarableTemplate<> class template,
which was an abstraction that didn't actually save anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148181 91177308-0d34-0410-b5e6-96231b3b80d8
go through a central allocation routine
Decl::AllocateDeserializedDecl(). No actual functionality change (yet).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147614 91177308-0d34-0410-b5e6-96231b3b80d8
accompanying fixes to make it work today.
The core of this patch is to provide a link from a TemplateTypeParmType
back to the TemplateTypeParmDecl node which declared it. This in turn
provides much more precise information about the type, where it came
from, and how it functions for AST consumers.
To make the patch work almost a year after its first attempt, it needed
serialization support, and it now retains the old getName() interface.
Finally, it requires us to not attempt to instantiate the type in an
unsupported friend decl -- specifically those coming from template
friend decls but which refer to a specific type through a dependent
name.
A cleaner representation of the last item would be to build
FriendTemplateDecl nodes for these, storing their template parameters
etc, and to perform proper instantation of them like any other template
declaration. They can still be flagged as unsupported for the purpose of
access checking, etc.
This passed an asserts-enabled bootstrap for me, and the reduced test
case mentioned in the original review thread no longer causes issues,
likely fixed at somewhere amidst the 24k revisions that have elapsed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130628 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127092 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127004 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126033 91177308-0d34-0410-b5e6-96231b3b80d8
Also, reorganize and make very explicit the logic for determining
the value kind and type of a referenced declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@125150 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123845 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123448 91177308-0d34-0410-b5e6-96231b3b80d8
in ASTContext-allocated memory, copying the provided template
arguments. Use this new routine where we can. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123289 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122890 91177308-0d34-0410-b5e6-96231b3b80d8
non-type template parameter pack, make sure to create a pack expansion
for the corresponding template argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122799 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122527 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122498 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119685 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118385 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113391 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109869 91177308-0d34-0410-b5e6-96231b3b80d8
This patch uses the newly added Latest field of CommonBase to provide
a getNextRedeclaration() implementation for RedeclarableTemplateDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109756 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a Latest field to RedeclarableTemplateDecl's CommonBase
class which is used to store the latest redeclaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109755 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109754 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108834 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108832 91177308-0d34-0410-b5e6-96231b3b80d8
(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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108253 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106532 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104633 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104465 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104194 91177308-0d34-0410-b5e6-96231b3b80d8
be a copy constructor (since it isn't one semantically)
and fix the ownership bits it sets to be correct!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104192 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103144 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102693 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@102407 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98134 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86777 91177308-0d34-0410-b5e6-96231b3b80d8
types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85500 91177308-0d34-0410-b5e6-96231b3b80d8
classes. Move its implementation into a new module.
This will seem marginally more justified in a bit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85499 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85447 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith