| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
FunctionDecl::isInlineSpecified/setInlineSpecified.
llvm-svn: 85305
|
| |
|
|
|
|
|
| |
function template specializations and member functions of class
template specializations.
llvm-svn: 85300
|
| |
|
|
|
|
|
|
|
| |
members that have a definition. Also, use
CheckSpecializationInstantiationRedecl as part of this instantiation
to make sure that we diagnose the various kinds of problems that can
occur with explicit instantiations.
llvm-svn: 85270
|
| |
|
|
|
|
|
|
|
| |
template instantiation. Preserve it through PCH. Show it off to the indexer.
I'm healthily ignoring the vector type cases because we don't have a sensible
TypeLoc implementation for them anyway.
llvm-svn: 84994
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
in the DeclaratorInfo, if one is present.
Preserve source information through template instantiation. This is made
more complicated by the possibility that ParmVarDecls don't have DIs, which
is possibly worth fixing in the future.
Also preserve source information for function parameters in ObjC method
declarations.
llvm-svn: 84971
|
| |
|
|
| |
llvm-svn: 84436
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
TypeLoc class names to be $(Type classname)Loc. Rewrite the visitor.
Provide skeleton implementations for all the new TypeLocs.
Handle all cases in PCH. Handle a few more cases when inserting
location information in SemaType.
It should be extremely straightforward to add new location information
to existing TypeLoc objects now.
llvm-svn: 84386
|
| |
|
|
|
|
|
|
|
| |
instantiation redeclaration semantics for function template
specializations and member functions of class template
specializations. Also, record the point of instantiation for
explicit-instantiated functions and static data members.
llvm-svn: 84188
|
| |
|
|
|
|
|
|
| |
class templates the proper linkage.
Daniel, please look over the CodeGenModule bits.
llvm-svn: 84140
|
| |
|
|
| |
llvm-svn: 84129
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template as a specialization. For example, this occurs with:
template<typename T>
struct X {
template<typename U> struct Inner { /* ... */ };
};
template<> template<typename T>
struct X<int>::Inner {
T member;
};
We need to treat templates that are member specializations as special
in two contexts:
- When looking for a definition of a member template, we look
through the instantiation chain until we hit the primary template
*or a member specialization*. This allows us to distinguish
between the primary "Inner" definition and the X<int>::Inner
definition, above.
- When computing all of the levels of template arguments needed to
instantiate a member template, don't add template arguments
from contexts outside of the instantiation of a member
specialization, since the user has already manually substituted
those arguments.
Fix up the existing test for p18, which was actually wrong (but we
didn't diagnose it because of our poor handling of member
specializations of templates), and add a new test for member
specializations of templates.
llvm-svn: 83974
|
| |
|
|
|
|
|
| |
instantiation has already been required. To do so, keep track of the
point of instantiation for anything that can be instantiated.
llvm-svn: 83890
|
| |
|
|
|
|
|
|
|
| |
users to
pass a LookupResult reference to lookup routines. Call out uses which assume a single
result.
llvm-svn: 83674
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
-Make TypeLoc's constructor public.
llvm-svn: 83088
|
| |
|
|
| |
llvm-svn: 83035
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
|
| |
|
|
|
|
|
|
| |
generated for an inline function definition, taking into account C99
and GNU inline/extern inline semantics. This solution is simpler,
cleaner, and fixes PR4536.
llvm-svn: 81670
|
| |
|
|
| |
llvm-svn: 81590
|
| |
|
|
| |
llvm-svn: 81589
|
| |
|
|
| |
llvm-svn: 81588
|
| |
|
|
|
|
|
|
|
|
| |
instantiation of a member function template or member function of a
class template to be out-of-line if the definition of that function
template or member function was defined out-of-line. This ensures that
we get the correct linkage for explicit instantiations of out-of-line
definitions.
llvm-svn: 81562
|
| |
|
|
|
|
|
|
|
|
|
| |
- Diagnose attempts to add default arguments to templates (or member
functions of templates) after the initial declaration (DR217).
- Improve diagnostics when a default argument is redefined. Now, the
note will always point at the place where the default argument was
previously defined, rather than pointing to the most recent
declaration of the function.
llvm-svn: 81548
|
| |
|
|
|
|
| |
specialization types differently.
llvm-svn: 81512
|
| |
|
|
| |
llvm-svn: 81346
|
| |
|
|
|
|
| |
Weinig!
llvm-svn: 81237
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
friends.
llvm-svn: 80977
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
reading source information for types.
DeclaratorInfo will contain a flat memory block for source information about a type that came out of a declarator.
TypeLoc and its subclasses will be used by clients as wrappers to "traverse" the memory block and read the information.
Both DeclaratorInfo and TypeLoc are not utilized in this commit.
llvm-svn: 79391
|
| |
|
|
| |
llvm-svn: 79070
|
| |
|
|
|
|
| |
definition of a tag, since tags rarely have more than one or two declarations
llvm-svn: 77546
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
llvm-svn: 77510
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Zaffanella, with tweaks from Abramo Bagnara.
llvm-svn: 76576
|
| |
|
|
|
|
| |
all declarations of the same decl" without knowing the exact type.
llvm-svn: 76298
|
| |
|
|
|
|
|
|
| |
defining the common interface for Decls that can be redeclared.
Make FunctionDecl and VarDecl use it.
llvm-svn: 76297
|
| |
|
|
|
|
| |
Their usefulness is questionable since redecl_iterator was introduced.
llvm-svn: 76275
|
| |
|
|
|
|
| |
method Decl::getCanonicalDecl().
llvm-svn: 76273
|
| |
|
|
|
|
|
|
|
| |
until Doug Gregor's Type smart pointer code lands (or more discussion occurs).
These methods just call the new Type::getAs<XXX> methods, so we still have
reduced implementation redundancy. Having explicit getAsXXXType() methods makes
it easier to set breakpoints in the debugger.
llvm-svn: 76193
|
| |
|
|
|
|
| |
Type::getAsMemberPointerType(), Type::getAsTagType(), and Type::getAsRecordType() with their Type::getAs<XXX> equivalents.
llvm-svn: 76139
|
| |
|
|
|
| |
Note: One day, it might be useful to consider adding this info to DeclGroup (as the comments in FunctionDecl/VarDecl suggest). For now, I think this works fine. I considered moving this to ValueDecl (a common ancestor of FunctionDecl/VarDecl/FieldDecl), however this would add overhead to EnumConstantDecl (which would burn memory and isn't necessary).
llvm-svn: 75635
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FunctionDecl or VarDecl.
It iterates over all the redeclarations, regardless of the starting point. For example:
1) int f();
2) int f();
3) int f();
if you have the (2) FunctionDecl and call redecls_begin/redecls_end to iterate, you'll get this sequence:
(2)
(1)
(3)
The motivation to introduce this was that, previously, if (3) was a function definition,
and you called getBody() at (2), it would not return it, since getBody() iterated over the previous declarations only,
so it would only check (2) and (1).
llvm-svn: 75604
|
| |
|
|
|
|
|
|
|
|
| |
VarDecl::getLatestDeclaration().
For multiple redeclarations they return the last one.
Also, add some non const versions of methods.
llvm-svn: 75603
|
| |
|
|
|
|
|
|
| |
VarDecl::getFirstDeclaration().
For multiple redeclarations they return the first one.
llvm-svn: 75602
|
| |
|
|
| |
llvm-svn: 75590
|