instantiation, to ensure that we mark class template specilizations as
abstract when we need to and perform checking of abstract classes.
Also, move the checking that determines whether we are creating a
variable of abstract class type *after* we check whether the type is
complete. Otherwise, we won't see when we have an abstract class
template specialization that is implicitly instantiated by this
declaration. This is the "something else" that Sebastian had noted
earlier.
llvm-svn: 90467
common to both parsing and template instantiation, so that we'll find
overridden virtuals for member functions of class templates when they
are instantiated.
Additionally, factor out the checking for pure virtual functions, so
that it will be executed both at parsing time and at template
instantiation time.
These changes fix PR5656 (for real), although one more tweak
w.r.t. member function templates will be coming along shortly.
llvm-svn: 90241
Create a new UnresolvedMemberExpr for these lookups. Assorted hackery
around qualified member expressions; this will all go away when we
implement the correct (i.e. extremely delayed) implicit-member semantics.
llvm-svn: 90161
function templates (in C++98), friend function templates, and
out-of-line definitions of members of class templates.
Also handles merging of default template arguments from previous
declarations of function templates, for C++0x. However, we don't yet
make use of those default template arguments.
llvm-svn: 89872
type and fixes a long-standing code gen. crash reported in
at least two PRs and a radar. (radar 7405040 and pr5025).
There are couple of remaining issues that I would like for
Ted. and Doug to look at:
Ted, please look at failure in Analysis/MissingDealloc.m.
I have temporarily added an expected-warning to make the
test pass. This tests has a declaration of 'SEL' type which
may not co-exist with the new changes.
Doug, please look at a FIXME in PCHWriter.cpp/PCHReader.cpp.
I think the changes which I have ifdef'ed out are correct. They
need be considered for in a few Indexer/PCH test cases.
llvm-svn: 89561
The following attributes are currently supported in C++0x attribute
lists (and in GNU ones as well):
- align() - semantics believed to be conformant to n3000, except for
redeclarations and what entities it may apply to
- final - semantics believed to be conformant to CWG issue 817's proposed
wording, except for redeclarations
- noreturn - semantics believed to be conformant to n3000, except for
redeclarations
- carries_dependency - currently ignored (this is an optimization hint)
llvm-svn: 89543
name 'T' is looked up in the expression
t.~T()
Previously, we weren't looking into the type of "t", and therefore
would fail when T actually referred to an injected-class-name. Fixes
PR5530.
llvm-svn: 89493
two classes, one for typenames and one for values; this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard. Track the location of the 'typename' keyword in a using-typename
decl. Make a new lookup result for unresolved values and deal with it in
most places.
llvm-svn: 89184
LookupResult RAII powers to diagnose ambiguity in the results. Other diagnostics
(e.g. access control and deprecation) will be moved to automatically trigger
during lookup as part of this same mechanism.
This abstraction makes it much easier to encapsulate aliasing declarations
(e.g. using declarations) inside the lookup system: eventually, lookup will
just produce the aliases in the LookupResult, and the standard access methods
will naturally strip the aliases off.
llvm-svn: 89027
sugared types. The basic problem is that our qualifier accessors
(getQualifiers, getCVRQualifiers, isConstQualified, etc.) only look at
the current QualType and not at any qualifiers that come from sugared
types, meaning that we won't see these qualifiers through, e.g.,
typedefs:
typedef const int CInt;
typedef CInt Self;
Self.isConstQualified() currently returns false!
Various bugs (e.g., PR5383) have cropped up all over the front end due
to such problems. I'm addressing this problem by splitting each
qualifier accessor into two versions:
- the "local" version only returns qualifiers on this particular
QualType instance
- the "normal" version that will eventually combine qualifiers from this
QualType instance with the qualifiers on the canonical type to
produce the full set of qualifiers.
This commit adds the local versions and switches a few callers from
the "normal" version (e.g., isConstQualified) over to the "local"
version (e.g., isLocalConstQualified) when that is the right thing to
do, e.g., because we're printing or serializing the qualifiers. Also,
switch a bunch of
Context.getCanonicalType(T1).getUnqualifiedType() == Context.getCanonicalType(T2).getQualifiedType()
expressions over to
Context.hasSameUnqualifiedType(T1, T2)
llvm-svn: 88969
handling template template parameters properly. This refactoring:
- Parses template template arguments as id-expressions, representing
the result of the parse as a template name (Action::TemplateTy)
rather than as an expression (lame!).
- Represents all parsed template arguments via a new parser-specific
type, ParsedTemplateArgument, which stores the kind of template
argument (type, non-type, template) along with all of the source
information about the template argument. This replaces an ad hoc
set of 3 vectors (one for a void*, which was either a type or an
expression; one for a bit telling whether the first was a type or
an expression; and one for a single source location pointing at
the template argument).
- Moves TemplateIdAnnotation into the new Parse/Template.h. It never
belonged in the Basic library anyway.
llvm-svn: 86708
ArrayType>()) does not instantiate. Update all callers that used this
unsafe feature to use the appropriate ASTContext::getAs*ArrayType method.
llvm-svn: 86596
appears in a deprecated context. In the new strategy, we emit the warnings
as usual unless we're currently parsing a declaration, where "declaration" is
restricted to mean a decl group or a few special cases in Objective C. If
we *are* parsing a declaration, we queue up the deprecation warnings until
the declaration has been completely parsed, and then emit them only if the
decl is not deprecated.
We also standardize the bookkeeping for deprecation so as to avoid special cases.
llvm-svn: 85998
yet another copy of the unqualified-id parsing code.
Also, use UnqualifiedId to simplify the Action interface for building
id-expressions. ActOnIdentifierExpr, ActOnCXXOperatorFunctionIdExpr,
ActOnCXXConversionFunctionExpr, and ActOnTemplateIdExpr have all been
removed in favor of the new ActOnIdExpression action.
llvm-svn: 85904
representation of a C++ unqualified-id, along with a single parsing
function (Parser::ParseUnqualifiedId) that will parse all of the
various forms of unqualified-id in C++.
Replace the representation of the declarator name in Declarator with
the new UnqualifiedId class, simplifying declarator-id parsing
considerably and providing more source-location information to
Sema. In the future, I hope to migrate all of the other
unqualified-id-parsing code over to this single representation, then
begin to merge actions that are currently only different because we
didn't have a unqualified notion of the name in the parser.
llvm-svn: 85851
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
process decl attributes instead of dropping them on the floor.
This allows us to diagnose cases like the testcase. Also don't
diagnose deprecated stuff in ActOnTag: not all uses of tags
may be 'uses', and SemaType does this now.
llvm-svn: 85071
types) out of Sema::getTypeName into ConvertDeclSpecToType. getTypeName
is sometimes used as a predicate in the parser, so it could cause redundant
diags to be emitted. This is also needed by two upcoming enhancements.
llvm-svn: 85070
IIDecl cannot be null. There is no need to check for both C++ mode and
presence of CXXRecordDecl. ObjC interfaces can't have ScopeSpecs.
llvm-svn: 85057
type looking using getTypeName() and every property access was using
NextToken() to do lookahead to see if the identifier is followed by
a '.'. Rearrange this code to not need lookahead and only do the
type lookup if we have "identifier." in the token stream. Also
improve a diagnostic a bit.
llvm-svn: 85056
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
to all callers. Switch a few other users of CK_Unknown to proper cast
kinds.
Note that there are still some situations where we end up with
CK_Unknown; they're pretty easy to find with grep. There
are still a few missing conversion kinds, specifically
pointer/int/float->bool and the various combinations of real/complex
float/int->real/complex float/int.
llvm-svn: 84623
TypeLoc records for declarations; it should not be necessary to represent it
directly in the type system.
Please complain if you were using these classes and feel you can't replicate
previous functionality using the TypeLoc API.
llvm-svn: 84222
unknown type name, e.g.,
foo::bar x;
when "bar" does not refer to a type in "foo".
With this change, the parser now calls into the action to perform
diagnostics and can try to recover by substituting in an appropriate
type. For example, this allows us to easily diagnose some missing
"typename" specifiers, which we now do:
test/SemaCXX/unknown-type-name.cpp:29:1: error: missing 'typename'
prior to dependent type name 'A<T>::type'
A<T>::type A<T>::f() { return type(); }
^~~~~~~~~~
typename
Fixes PR3990.
llvm-svn: 84053
what we found when we looked into <blah>", where <blah> is a
DeclContext*. We can now format DeclContext*'s in nice ways, e.g.,
"namespace N", "the global namespace", "'class Foo'".
This is part of PR3990, but we're not quite there yet.
llvm-svn: 84028
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
function templates.
This commit ensures that friend function templates are constructed as
FunctionTemplateDecls rather than partial FunctionDecls (as they
previously were). It then implements template instantiation for friend
function templates, injecting the friend function template only when
no previous declaration exists at the time of instantiation.
Oh, and make sure that explicit specialization declarations are not
friends.
llvm-svn: 83970
that are declarations (rather than definitions). Also, be sure to set
the access specifiers properly when instantiating the declarations of
member function templates.
llvm-svn: 83911
function and member function templates that are not definitions. Add
more tests to ensure that explicit specializations of member function
templates prevent instantiation.
llvm-svn: 83550
templates, and keep track of how those member classes were
instantiated or specialized.
Make sure that we don't try to instantiate an explicitly-specialized
member class of a class template, when that explicit specialization
was a declaration rather than a definition.
llvm-svn: 83547
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
templates. Previously, these weren't handled as specializations at
all. The AST for representing these as specializations is still a work
in progress.
llvm-svn: 83498
for bases, members, overridden virtual methods, etc. The operations
isDerivedFrom and lookupInBases are now provided by CXXRecordDecl,
rather than by Sema, so that CodeGen and other clients can use them
directly.
llvm-svn: 83396
of the flow-control checks for falling off the end of a function,
since the return type may instantiate to void. Similarly, if a
return statement has an expression and the return type of the function
is void, don't complain if the expression is type-dependent, since
that type could instantiate to void.
Fixes PR5071.
llvm-svn: 83222
functions that occur in multiple declaration contexts, e.g., because
some were found via using declarations. Now, isDeclInScope will build
a new overload set (when needed) containing only those declarations
that are actually in scope. This eliminates a problem found with
libstdc++'s <iostream>, where the presence of using
In the longer term, I'd like to eliminate Sema::isDeclInScope in favor
of better handling of the RedeclarationOnly flag in the name-lookup
routines. That way, name lookup only returns the entities that matter,
rather than taking the current two-pass approach of producing too many
results and then filtering our the wrong results. It's not efficient,
and I'm sure that we aren't filtering everywhere we should be.
llvm-svn: 82954
class templates. We now treat friend class templates much more like
normal class templates, except that they still get special name lookup
rules. Fixes PR5057 and eliminates a bunch of spurious diagnostics in
<iostream>.
llvm-svn: 82848
template void f<int>(int);
~~~~~~
Previously, we silently dropped the template arguments. With this
change, we now use the template arguments (when available) as the
explicitly-specified template arguments used to aid template argument
deduction for explicit template instantiations.
llvm-svn: 82806
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
Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our
use of qualifiers and fix a few places that weren't dealing with qualifiers
quite right; many more remain.
llvm-svn: 82705
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
give them the appropriate exception specifications. This,
unfortunately, requires us to maintain and/or implicitly generate
handles to namespace "std" and the class "std::bad_alloc". However,
every other approach I've come up with was more hackish, and this
standard requirement itself is quite the hack.
Fixes PR4829.
llvm-svn: 81939
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
such initializations properly convert constructor arguments and fill
in default arguments where necessary. This also makes the ownership
model more clear.
llvm-svn: 81394
order because it was doing so while iterating over a densemap.
There are still similar problems in other places, for example
WeakUndeclaredIdentifiers is still written to the PCH file in a nondeterminstic
order, and we emit warnings about #pragma weak in nondeterminstic order.
llvm-svn: 81236
ways: remove elab types during desugaring, enhance pretty-printing to allow
tags to be suppressed without suppressing scopes, look through elab types
when associating a typedef name with an anonymous record type.
llvm-svn: 81065
of any previous declaration in case we replace it in a class's declaration table.
Fixes bug 4858. This sort of thing makes me reconsider putting friend declarations in
declaration lists.
llvm-svn: 80750
declarations of same, introduce a single AST class and add appropriate bits
(encoded in the namespace) for whether a decl is "real" or not. Much hackery
about previously-declared / not-previously-declared, but it's essentially
mandated by the standard that friends alter lookup, and this is at least
fairly non-intrusive.
Refactor the Sema methods specific to friends for cleaner flow and less nesting.
Incidentally solve a few bugs, but I remain confident that we can put them back.
llvm-svn: 80353
templates within class templates, producing a member function template
of a class template specialization. If you can parse that, I'm
sorry. Example:
template<typename T>
struct X {
template<typename U> void f(T, U);
};
When we instantiate X<int>, we now instantiate the declaration
X<int>::f, which looks like this:
template<typename U> void X<int>::f(int, U);
The path this takes through
TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and
ugly, but I don't know how to improve it yet. I'm resting my hopes on
the multi-level substitution required to instantiate definitions of
nested templates, which may simplify this code as well.
More testing to come...
llvm-svn: 80252
TypenameType if getTypeName is looking at a member of an unknown
specialization. This allows us to properly parse class templates that
derived from type that could only otherwise be described by a typename type,
e.g.,
template<class T> struct X {};
template<typename T> struct Y : public X<T>::X { };
Fixes PR4381.
llvm-svn: 80123
qualified name does not actually refer into a class/class
template/class template partial specialization.
Improve printing of nested-name-specifiers to eliminate redudant
qualifiers. Also, make it possible to output a nested-name-specifier
through a DiagnosticBuilder, although there are relatively few places
that will use this leeway.
llvm-svn: 80056
their members, including member class template, member function
templates, and member classes and functions of member templates.
To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,
template<typename X> template<typename Y>
X Outer<X>::Inner1<Y>::foo(Y) {
return X();
}
we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.
Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.
llvm-svn: 80044
accurately. Prevents the assert from triggering incorrectly when friending
functions first declared in extern "C" contexts. Fixes bug 4757.
llvm-svn: 80016
the logic is there for out-of-line definitions with multiple levels of
nested templates, but this is still a work-in-progress: we're having
trouble determining when we should look into a dependent
nested-name-specifier.
llvm-svn: 80003
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
Anders Carlsson