"->" with a use of ParseUnqualifiedId. Collapse
ActOnMemberReferenceExpr, ActOnDestructorReferenceExpr (both of them),
ActOnOverloadedOperatorReferenceExpr,
ActOnConversionOperatorReferenceExpr, and
ActOnMemberTemplateIdReferenceExpr into a single, new action
ActOnMemberAccessExpr that does the same thing more cleanly (and can
keep more source-location information).
llvm-svn: 85930
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
parameters and template type parameters, which occurs when
substituting into the declarations of member templates inside class
templates. This eliminates errors about our inability to "reduce
non-type template parameter depth", fixing PR5311.
Also fixes a bug when instantiating a template type parameter
declaration in a member template, where we weren't properly reducing
the template parameter's depth.
LLVM's StringSwitch header now parses.
llvm-svn: 85669
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
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
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
instantiation once we have committed to performing the
instantiation. As part of this, make our makeshift
template-instantiation location information suck slightly less.
Fixes PR5264.
llvm-svn: 85209
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
the DeclaratorInfo, one for semantic analysis), just build a single type whose
canonical type will reflect the semantic analysis (assuming the type is
well-formed, of course).
To make that work, make a few changes to the type system:
* allow the nominal pointee type of a reference type to be a (possibly sugared)
reference type. Also, preserve the original spelling of the reference type.
Both of these can be ignored on canonical reference types.
* Remove ObjCProtocolListType and preserve the associated source information on
the various ObjC TypeLocs. Preserve the spelling of protocol lists except in
the canonical form.
* Preserve some level of source type structure on parameter types, but
canonicalize on the canonical function type. This is still a WIP.
Drops code size, makes strides towards accurate source location representation,
slight (~1.7%) progression on Cocoa.h because of complexity drop.
llvm-svn: 84907
N::f<int>
keep track of the full nested-name-specifier. This is mainly QoI and
relatively hard to test; will try to come up with a printing-based
test once we also retain the explicit template arguments past overload
resolution.
llvm-svn: 84869
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
Taking the address of an overloaded function with an explicit address-of operator wrapped the operator in an implicit cast that added yet another pointer level, leaving us with a corrupted AST, which crashed CodeGen in the test case I've added. Fix this by making FixOverloadedFunctionReference return whether there was an address-of operator and not adding the implicit cast in that case.
llvm-svn: 84362
functions/static data members of class template specializations that
do not have definitions. This is the latter part of [temp.explicit]p4;
the former part still needs more testing.
llvm-svn: 84182
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
conditions. Add a fixit to insert the parentheses. Also fix a very minor
possible memory leak in 'for' conditions.
Fixes PR 4876 and rdar://problem/7289172
llvm-svn: 83907
The exception specification of the assignee must be the same or a subset of the target. In addition, exception specifications on arguments and return types must be equivalent, but this is not implemented yet.
This currently produces two diagnostics for every invalid assignment/initialization, due to the diagnostic produced outside PerformImplicitConversion, e.g. in CheckSingleInitializer. I don't know how to suppress this; in any case I think it is the wrong place for a diagnostic, since there are other diagnostics produced inside the function. So I'm leaving it as it is for the moment.
llvm-svn: 83710
struct B;
B f();
void g() {
f();
}
We now get
t.cpp:6:3: error: calling 'f' with incomplete return type 'struct B'
f();
^~~
t.cpp:3:3: note: 'f' declared here
B f();
^
t.cpp:1:8: note: forward declaration of 'struct B'
struct B;
^
llvm-svn: 83692
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
declarations and explicit template instantiations, improving
diagnostics and making the code usable for function template
specializations (as well as class template specializations and partial
specializations).
llvm-svn: 83436
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
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
member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.
llvm-svn: 82789
value-dependent. Audit (and fixed) all calls to
Expr::isNullPointerConstant() to provide the correct behavior with
value-dependent expressions. Fixes PR5041 and a crash in libstdc++
<locale>.
In the same vein, properly compute value- and type-dependence for
ChooseExpr. Fixes PR4996.
llvm-svn: 82748
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
It uses a recent API to find inherited conversion functions to do
the initializer to reference lvalue conversion (and removes a FIXME).
It issues the ambiguity diagnostics when multiple conversions are found.
WIP.
llvm-svn: 82649
opening parentheses and after each comma. We gather the set of visible
overloaded functions, perform "partial" overloading based on the set
of arguments that we have thus far, and return the still-viable
results sorted by the likelihood that they will be the best candidate.
Most of the changes in this patch are a refactoring of the overloading
routines for a function call, since we needed to separate out the
notion of building an overload set (common to code-completion and
normal semantic analysis) and then what to do with that overload
set. As part of this change, I've pushed explicit template arguments
into a few more subroutines.
There is still much more work to do in this area. Function templates
won't be handled well (unless we happen to deduce all of the template
arguments before we hit the completion point), nor will overloaded
function-call operators or calls to member functions.
llvm-svn: 82549
template smarter, by taking into account which function template
parameters are deducible from the call arguments. For example,
template<typename RandomAccessIterator>
void sort(RandomAccessIterator first, RandomAccessIterator last);
will have a code-completion string like
sort({RandomAccessIterator first}, {RandomAccessIterator last})
since the template argument for its template parameter is
deducible. On the other hand,
template<class X, class Y>
X* dyn_cast(Y *Val);
will have a code-completion string like
dyn_cast<{class X}>({Y *Val})
since the template type parameter X is not deducible from the function
call.
llvm-svn: 82306
- after "using", show anything that can be a nested-name-specifier.
- after "using namespace", show any visible namespaces or namespace aliases
- after "namespace", show any namespace definitions in the current scope
- after "namespace identifier = ", show any visible namespaces or
namespace aliases
llvm-svn: 82251
will provide the names of various enumerations currently
visible. Introduced filtering of code-completion results when we build
the result set, so that we can identify just the kinds of declarations
we want.
This implementation is incomplete for C++, since we don't consider
that the token after the tag keyword could start a
nested-name-specifier.
llvm-svn: 82222
essence, code completion is triggered by a magic "code completion"
token produced by the lexer [*], which the parser recognizes at
certain points in the grammar. The parser then calls into the Action
object with the appropriate CodeCompletionXXX action.
Sema implements the CodeCompletionXXX callbacks by performing minimal
translation, then forwarding them to a CodeCompletionConsumer
subclass, which uses the results of semantic analysis to provide
code-completion results. At present, only a single, "printing" code
completion consumer is available, for regression testing and
debugging. However, the design is meant to permit other
code-completion consumers.
This initial commit contains two code-completion actions: one for
member access, e.g., "x." or "p->", and one for
nested-name-specifiers, e.g., "std::". More code-completion actions
will follow, along with improved gathering of code-completion results
for the various contexts.
[*] In the current -code-completion-dump testing/debugging mode, the
file is truncated at the completion point and EOF is translated into
"code completion".
llvm-svn: 82166
when we are not instantiating the corresponding "current
instantiation." This happens, e.g., when we are instantiating a
declaration reference that refers into the "current instantiation" but
occurs in a default function argument. The libstdc++ vector default
constructor now instantiates properly.
llvm-svn: 82069
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
MarkUsedTemplateParameters, which is able to mark template parameters
used within non-deduced contexts as well as deduced contexts. Use this
to finish the implementation of [temp.deduct.partial]p11.
llvm-svn: 81794
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
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
formed without a trailing '(', diagnose the error (these expressions
must be immediately called), emit a fix-it hint, and fix the code.
llvm-svn: 81015
involve qualified names, e.g., x->Base::f. We now maintain enough
information in the AST to compare the results of the name lookup of
"Base" in the scope of the postfix-expression (determined at template
definition time) and in the type of the object expression.
llvm-svn: 80953
x->Base::f
We no longer try to "enter" the context of the type that "x" points
to. Instead, we drag that object type through the parser and pass it
into the Sema routines that need to know how to perform lookup within
member access expressions.
We now implement most of the crazy name lookup rules in C++
[basic.lookup.classref] for non-templated code, including performing
lookup both in the context of the type referred to by the member
access and in the scope of the member access itself and then detecting
ambiguities when the two lookups collide (p1 and p4; p3 and p7 are
still TODO). This change also corrects our handling of name lookup
within template arguments of template-ids inside the
nested-name-specifier (p6; we used to look into the scope of the
object expression for them) and fixes PR4703.
I have disabled some tests that involve member access expressions
where the object expression has dependent type, because we don't yet
have the ability to describe dependent nested-name-specifiers starting
with an identifier.
llvm-svn: 80843
When performing template instantiation of the definitions of member
templates (or members thereof), we build a data structure containing
the template arguments from each "level" of template
instantiation. During template instantiation, we substitute all levels
of template arguments simultaneously.
llvm-svn: 80389
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
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
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
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
that type. Note that we do not produce a diagnostic if the type is
incomplete; rather, we just don't look for conversion functions. Fixes PR4660.
llvm-svn: 79919
- Allowing one to name a member function template within a class
template and on the right-hand side of a member access expression.
- Template argument deduction for calls to member function templates.
- Registering specializations of member function templates (and
finding them later).
llvm-svn: 79581
where sizeof(short) == sizeof(int). Move UsualArithmeticConversionsType
out of Sema, since it was only there as a historical artifact. Patch by
Enea Zaffanella.
llvm-svn: 79412
This is a Type subclass that can hold a DeclaratorInfo* when we have type source info coming
out of a declarator that we want to preserve. This is used only at the "border" of Parser/Sema for
passing/getting QualTypes, it does not participate in the type system semantics in any way.
llvm-svn: 79394
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
FriendFunctionDecl, and create instances as appropriate.
The design of FriendFunctionDecl is still somewhat up in the air; you can
befriend arbitrary types of functions --- methods, constructors, etc. ---
and it's not clear that this representation captures that very well.
We'll have a better picture when we start consuming this data in access
control.
llvm-svn: 78653
Fixes PR4704 problems
Addresses Eli's patch feedback re: ugly cast code
Updates all postfix operators to remove ParenListExprs. While this is awful,
no better solution (say, in the parser) is obvious to me. Better solutions
welcome.
llvm-svn: 78621
--- Reverse-merging r78535 into '.':
D test/Sema/altivec-init.c
U include/clang/Basic/DiagnosticSemaKinds.td
U include/clang/AST/Expr.h
U include/clang/AST/StmtNodes.def
U include/clang/Parse/Parser.h
U include/clang/Parse/Action.h
U tools/clang-cc/clang-cc.cpp
U lib/Frontend/PrintParserCallbacks.cpp
U lib/CodeGen/CGExprScalar.cpp
U lib/Sema/SemaInit.cpp
U lib/Sema/Sema.h
U lib/Sema/SemaExpr.cpp
U lib/Sema/SemaTemplateInstantiateExpr.cpp
U lib/AST/StmtProfile.cpp
U lib/AST/Expr.cpp
U lib/AST/StmtPrinter.cpp
U lib/Parse/ParseExpr.cpp
U lib/Parse/ParseExprCXX.cpp
llvm-svn: 78551
In addition to being defined by the AltiVec PIM, this is also the vector
initializer syntax used by OpenCL, so that vector literals are compatible
with macro arguments.
llvm-svn: 78535
we were going to enter into the scope of a class template or class
template partial specialization, rebuild that type so that it can
refer to members of the current instantiation, as in code like
template<typename T>
struct X {
typedef T* pointer;
pointer data();
};
template<typename T>
typename X<T>::pointer X<T>::data() { ... }
Without rebuilding the return type of this out-of-line definition, the
canonical return type of the out-of-line definition (a TypenameType)
will not match the canonical return type of the declaration (the
canonical type of T*).
llvm-svn: 78316
implementation of '#pragma unused' by not constructing intermediate
DeclRefExprs, but instead do the name lookup directly. The
implementation is greatly simplified.
Along the way, degrade '#pragma unused(undeclaredvariable)' to a
warning instead of being a hard error. This implements:
<rdar://problem/6761874> [sema] allow #pragma unused to reference undefined variable (with warning)
llvm-svn: 78019
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
point that covers templates and non-templates. This should eliminate
the flood of warnings I introduced yesterday.
Removed the ActOnClassTemplate action, which is no longer used.
llvm-svn: 76881
- Move Sema::ObjCQualifiedIdTypesAreCompatible(), Sema::QualifiedIdConformsQualifiedId(), and a couple helper functions to ASTContext.
- Change ASTContext::canAssignObjCInterfaces() to use ASTContext:: ObjCQualifiedIdTypesAreCompatible().
- Tweak several test cases to accommodate the new/improved type checking.
llvm-svn: 76830
value. This is on by default, and controlled by -Wreturn-type (-Wmost
-Wall). I believe there should be very few false positives, though
the most interesting case would be:
int() { bar(); }
when bar does:
bar() { while (1) ; }
Here, we assume functions return, unless they are marked with the
noreturn attribute. I can envision a fixit note for functions that
never return normally that don't have a noreturn attribute to add a
noreturn attribute.
If anyone spots other false positives, let me know!
llvm-svn: 76821
templates, e.g.,
template<typename T>
struct Outer {
struct Inner;
};
template<typename T>
struct Outer<T>::Inner {
// ...
};
Implementing this feature required some extensions to ActOnTag, which
now takes a set of template parameter lists, and is the precursor to
removing the ActOnClassTemplate function from the parser Action
interface. The reason for this approach is simple: the parser cannot
tell the difference between a class template definition and the
definition of a member of a class template; both have template
parameter lists, and semantic analysis determines what that template
parameter list means.
There is still some cleanup to do with ActOnTag and
ActOnClassTemplate. This commit provides the basic functionality we
need, however.
llvm-svn: 76820
Douglas Gregor