are for out of line declarations more easily. This simplifies the logic and
handles the case of out-of-line class definitions correctly. Fixes PR6107.
llvm-svn: 96729
array allocated using the allocator in ASTContext. This addresses
these strings getting leaked when using a BumpPtrAllocator (in
ASTContext).
Fixes: <rdar://problem/7636765>
llvm-svn: 95853
of a C++ record. Exposed a lot of problems where various routines were
silently doing The Wrong Thing (or The Acceptable Thing in The Wrong Order)
when presented with a non-definition. Also cuts down on memory usage.
llvm-svn: 95330
that is in an anonymous namespace, give that function or variable
internal linkage.
This change models an oddity of the C++ standard, where names declared
in an anonymous namespace have external linkage but, because anonymous
namespace are really "uniquely-named" namespaces, the names cannot be
referenced from other translation units. That means that they have
external linkage for semantic analysis, but the only sensible
implementation for code generation is to give them internal
linkage. We now model this notion via the UniqueExternalLinkage
linkage type. There are several changes here:
- Extended NamedDecl::getLinkage() to produce UniqueExternalLinkage
when the declaration is in an anonymous namespace.
- Added Type::getLinkage() to determine the linkage of a type, which
is defined as the minimum linkage of the types (when we're dealing
with a compound type that is not a struct/class/union).
- Extended NamedDecl::getLinkage() to consider the linkage of the
template arguments and template parameters of function template
specializations and class template specializations.
- Taught code generation to rely on NamedDecl::getLinkage() when
determining the linkage of variables and functions, also
considering the linkage of the types of those variables and
functions (C++ only). Map UniqueExternalLinkage to internal
linkage, taking out the explicit checks for
isInAnonymousNamespace().
This fixes much of PR5792, which, as discovered by Anders Carlsson, is
actually the reason behind the pass-manager assertion that causes the
majority of clang-on-clang regression test failures. With this fix,
Clang-built-Clang+LLVM passes 88% of its regression tests (up from
67%). The specific numbers are:
LLVM:
Expected Passes : 4006
Expected Failures : 32
Unsupported Tests : 40
Unexpected Failures: 736
Clang:
Expected Passes : 1903
Expected Failures : 14
Unexpected Failures: 75
Overall:
Expected Passes : 5909
Expected Failures : 46
Unsupported Tests : 40
Unexpected Failures: 811
Still to do:
- Improve testing
- Check whether we should allow the presence of types with
InternalLinkage (in addition to UniqueExternalLinkage) given
variables/functions internal linkage in C++, as mentioned in
PR5792.
- Determine how expensive the getLinkage() calls are in practice;
consider caching the result in NamedDecl.
- Assess the feasibility of Chris's idea in comment #1 of PR5792.
llvm-svn: 95216
region of interest (if provided). Implement clang_getCursor() in terms
of this traversal rather than using the Index library; the unified
cursor visitor is more complete, and will be The Way Forward.
Minor other tweaks needed to make this work:
- Extend Preprocessor::getLocForEndOfToken() to accept an offset
from the end, making it easy to move to the last character in the
token (rather than just past the end of the token).
- In Lexer::MeasureTokenLength(), the length of whitespace is zero.
llvm-svn: 94200
"integer promotion" type associated with an enum decl, and use this type to
determine which type to promote to. This type obeys C++ [conv.prom]p2 and
is therefore generally signed unless the range of the enumerators forces
it to be unsigned.
Kills off a lot of false positives from -Wsign-compare in C++, addressing
rdar://7455616
llvm-svn: 90965
class A {
inline void f();
}
void A::f() { }
This is not the most ideal solution, since it doesn't work 100% with regular functions (as my FIXME comment states).
llvm-svn: 90607
the linkage of a declaration. Switch the lame (and completely wrong)
NamedDecl::hasLinkage() over to using the new NamedDecl::getLinkage(),
along with the "can this declaration be a template argument?" check
that started all of this.
Fixes -fsyntax-only for PR5597.
llvm-svn: 89891
inlined functions. For example, given
template<typename T>
class string {
unsigned Len;
public:
unsigned size() const { return Len; }
};
extern template class string<char>;
we now give the instantiation of string<char>::size
available_externally linkage (if it is ever instantiated!), as
permitted by the C++0x standard.
llvm-svn: 85340
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
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
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
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
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
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
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
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
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
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
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
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
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
When a Decl subclass can have multiple re-declarations in the same declaration context (like FunctionDecl),
getPrimaryDecl() will return a particular Decl that all of them will point to as the "primary" declaration.
llvm-svn: 74800
The implementations of these methods can Use Decl::getASTContext() to get the ASTContext.
This commit touches a lot of files since call sites for these methods are everywhere.
I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it.
llvm-svn: 74501
This is simple enough, but then I thought it would be nice to make PrintingPolicy
get a LangOptions so that various things can key off "bool" and "C++" independently.
This spiraled out of control. There are many fixme's, but I think things are slightly
better than they were before.
One thing that can be improved: CFG should probably have an ASTContext pointer in it,
which would simplify its clients.
llvm-svn: 74493
- Track implicit instantiations vs. the not-yet-supported explicit
specializations
- Give implicit instantiations of function templates (and member
functions of class templates) linkonce_odr linkage.
- Improve name mangling for function template specializations,
including the template arguments of the instantiation and the return
type of the function.
Note that our name-mangling is improved, but not correct: we still
don't mangle substitutions, although the manglings we produce can be
demangled.
llvm-svn: 74466
-Introduce Decl::getASTContext() which returns the reference from the TranslationUnitDecl that it is contained in.
The general idea is that Decls can point to their own ASTContext so that it is no longer required to "manually" keep track and make sure that you pass the correct ASTContext to Decls' methods, e.g. methods like Decl::getAttrs should eventually not require a ASTContext parameter.
llvm-svn: 74434
For a FunctionDecl that has been instantiated due to template argument
deduction, we now store the primary template from which it was
instantiated and the deduced template arguments. From this
information, we can instantiate the body of the function template.
llvm-svn: 74232
templates.
For example, this now type-checks (but does not instantiate the body
of deref<int>):
template<typename T> T& deref(T* t) { return *t; }
void test(int *ip) {
int &ir = deref(ip);
}
Specific changes/additions:
* Template argument deduction from a call to a function template.
* Instantiation of a function template specializations (just the
declarations) from the template arguments deduced from a call.
* FunctionTemplateDecls are stored directly in declaration contexts
and found via name lookup (all forms), rather than finding the
FunctionDecl and then realizing it is a template. This is
responsible for most of the churn, since some of the core
declaration matching and lookup code assumes that all functions are
FunctionDecls.
llvm-svn: 74213
Add initial support for NamespaceDecl, VarDecl, and FunctionDecl:
-NamespaceDecl range is from name to '}'
-VarDecl is from name to possible init expression
-FunctionDecl is from name to last parameter name or to end of its function body.
llvm-svn: 73821
preprocessor and initialize it early in clang-cc. This
ensures that __has_builtin works in all modes, not just
when ASTContext is around.
llvm-svn: 73319
printing logic to help customize the output. For now, we use this
rather than a special flag to suppress the "struct" when printing
"struct X" and to print the Boolean type as "bool" in C++ but "_Bool"
in C.
llvm-svn: 72590
given DeclContext is dependent on type parameters. Use this to
properly determine whether a TagDecl is dependent; previously, we were
missing the case where the TagDecl is a local class of a member
function of a class template (phew!).
Also, make sure that, when we instantiate declarations within a member
function of a class template (or a function template, eventually),
that we add those declarations to the "instantiated locals" map so
that they can be found when instantiating declaration references.
Unfortunately, I was not able to write a useful test for this change,
although the assert() that fires when uncommenting the FIXME'd line in
test/SemaTemplate/instantiate-declref.cpp tells the "experienced user"
that we're now doing the right thing.
llvm-svn: 72526
an integral constant expression, maintain a cache of the value and the
is-an-ICE flag within the VarDecl itself. This eliminates
exponential-time behavior of the Fibonacci template metaprogram.
llvm-svn: 72428
Chandler Carruth