maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/lib/Parse/ParseExprCXX.cpp

1965 lines
69 KiB
C++
Raw Normal View History

Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
//===--- ParseExprCXX.cpp - C++ Expression Parsing ------------------------===//
//
// The LLVM Compiler Infrastructure
//
Don't attribute in file headers anymore. See llvmdev for the discussion of this change. llvm-svn: 45410
2007-12-30 03:59:25 +08:00
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
//
//===----------------------------------------------------------------------===//
//
// This file implements the Expression parsing implementation for C++.
//
//===----------------------------------------------------------------------===//
move library-specific diagnostic headers into library private dirs. Reduce redundant #includes. Patch by Anders Johnsen! llvm-svn: 63271
2009-01-29 13:15:15 +08:00
#include "clang/Parse/ParseDiagnostic.h"
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
#include "clang/Parse/Parser.h"
Another step in the process of making the parser depend on Sema: - move DeclSpec &c into the Sema library - move ParseAST into the Parse library Reflect this change in a thousand different includes. Reflect this change in the link orders. llvm-svn: 111667
2010-08-21 02:27:03 +08:00
#include "clang/Sema/DeclSpec.h"
#include "clang/Sema/ParsedTemplate.h"
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
#include "llvm/Support/ErrorHandling.h"
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
using namespace clang;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
/// \brief Parse global scope or nested-name-specifier if present.
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
///
/// Parses a C++ global scope specifier ('::') or nested-name-specifier (which
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
/// may be preceded by '::'). Note that this routine will not parse ::new or
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
/// ::delete; it will just leave them in the token stream.
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
///
/// '::'[opt] nested-name-specifier
/// '::'
///
/// nested-name-specifier:
/// type-name '::'
/// namespace-name '::'
/// nested-name-specifier identifier '::'
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
/// nested-name-specifier 'template'[opt] simple-template-id '::'
///
///
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
/// \param SS the scope specifier that will be set to the parsed
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
/// nested-name-specifier (or empty)
///
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
/// \param ObjectType if this nested-name-specifier is being parsed following
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
/// the "." or "->" of a member access expression, this parameter provides the
/// type of the object whose members are being accessed.
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
///
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
/// \param EnteringContext whether we will be entering into the context of
/// the nested-name-specifier after parsing it.
///
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
/// \param MayBePseudoDestructor When non-NULL, points to a flag that
/// indicates whether this nested-name-specifier may be part of a
/// pseudo-destructor name. In this case, the flag will be set false
/// if we don't actually end up parsing a destructor name. Moreorover,
/// if we do end up determining that we are parsing a destructor name,
/// the last component of the nested-name-specifier is not parsed as
/// part of the scope specifier.
Implement support for parsing pseudo-destructor expression with a nested-name-specifier, e.g., typedef int Int; int *p; p->Int::~Int(); This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression. llvm-svn: 96743
2010-02-22 02:36:56 +08:00
/// member access expression, e.g., the \p T:: in \p p->T::m.
///
Fix an assertion-on-error during tentative constructor parsing by propagating error conditions out of the various annotate-me-a-snowflake routines. Generally (but not universally) removes redundant diagnostics as well as, you know, not crashing on bad code. On the other hand, I have just signed myself up to fix fiddly parser errors for the next week. Again. llvm-svn: 97221
2010-02-26 16:45:28 +08:00
/// \returns true if there was an error parsing a scope specifier
Improve support for out-of-line definitions of nested templates and 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
2009-08-26 06:51:20 +08:00
bool Parser::ParseOptionalCXXScopeSpecifier(CXXScopeSpec &SS,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ParsedType ObjectType,
Implement support for parsing pseudo-destructor expression with a nested-name-specifier, e.g., typedef int Int; int *p; p->Int::~Int(); This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression. llvm-svn: 96743
2010-02-22 02:36:56 +08:00
bool EnteringContext,
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
bool *MayBePseudoDestructor) {
Implement some suggestions by Daniel: -Change Parser::ParseCXXScopeSpecifier to MaybeParseCXXScopeSpecifier -Remove Parser::isTokenCXXScopeSpecifier and fold it into MaybeParseCXXScopeSpecifier -Rename Parser::TryAnnotateScopeToken to TryAnnotateCXXScopeToken and only allow it to be called when in C++ llvm-svn: 60117
2008-11-27 05:41:52 +08:00
assert(getLang().CPlusPlus &&
TryAnnotateTypeOrScopeToken and TryAnnotateCXXScopeToken can only be called when they might be needed now, so make them assert that their current token is :: or identifier. llvm-svn: 61662
2009-01-05 09:24:05 +08:00
"Call sites of this function should be guarded by checking for C++");
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
if (Tok.is(tok::annot_cxxscope)) {
Sundry incremental steps towards killing off Action. llvm-svn: 111795
2010-08-23 14:44:23 +08:00
SS.setScopeRep(static_cast<NestedNameSpecifier*>(Tok.getAnnotationValue()));
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
SS.setRange(Tok.getAnnotationRange());
ConsumeToken();
Fix an assertion-on-error during tentative constructor parsing by propagating error conditions out of the various annotate-me-a-snowflake routines. Generally (but not universally) removes redundant diagnostics as well as, you know, not crashing on bad code. On the other hand, I have just signed myself up to fix fiddly parser errors for the next week. Again. llvm-svn: 97221
2010-02-26 16:45:28 +08:00
return false;
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
}
minor simplifications. llvm-svn: 61637
2009-01-05 05:14:15 +08:00
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
bool HasScopeSpecifier = false;
remove optimization to avoid looking ahead for cases like ::foo. This isn't worth the complexity and the code already does a ton of lookahead. llvm-svn: 61671
2009-01-05 11:55:46 +08:00
if (Tok.is(tok::coloncolon)) {
// ::new and ::delete aren't nested-name-specifiers.
tok::TokenKind NextKind = NextToken().getKind();
if (NextKind == tok::kw_new || NextKind == tok::kw_delete)
return false;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
ParseCXXSimpleTypeSpecifier can only be called on things that are verified to be simple type specifiers, so there is no need for it to call TryAnnotateTypeOrScopeToken. Make MaybeParseCXXScopeSpecifier reject ::new and ::delete with a hard error now that it may never be transitively called in a context where these are legal. This allows me to start disentangling things more. llvm-svn: 61659
2009-01-05 08:13:00 +08:00
// '::' - Global scope qualifier.
simplify some code. llvm-svn: 61668
2009-01-05 10:07:19 +08:00
SourceLocation CCLoc = ConsumeToken();
SS.setBeginLoc(CCLoc);
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
SS.setScopeRep(Actions.ActOnCXXGlobalScopeSpecifier(getCurScope(), CCLoc));
simplify some code. llvm-svn: 61668
2009-01-05 10:07:19 +08:00
SS.setEndLoc(CCLoc);
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
HasScopeSpecifier = true;
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
}
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
bool CheckForDestructor = false;
if (MayBePseudoDestructor && *MayBePseudoDestructor) {
CheckForDestructor = true;
*MayBePseudoDestructor = false;
}
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
while (true) {
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
if (HasScopeSpecifier) {
// C++ [basic.lookup.classref]p5:
// If the qualified-id has the form
Initial stab at implement dependent member references to member templates, e.g., x.template get<T> We can now parse these, represent them within an UnresolvedMemberExpr expression, then instantiate that expression node in simple cases. This allows us to stumble through parsing LLVM's Casting.h. llvm-svn: 81300
2009-09-09 08:23:06 +08:00
//
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
// ::class-name-or-namespace-name::...
Initial stab at implement dependent member references to member templates, e.g., x.template get<T> We can now parse these, represent them within an UnresolvedMemberExpr expression, then instantiate that expression node in simple cases. This allows us to stumble through parsing LLVM's Casting.h. llvm-svn: 81300
2009-09-09 08:23:06 +08:00
//
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
// the class-name-or-namespace-name is looked up in global scope as a
// class-name or namespace-name.
//
// To implement this, we clear out the object type as soon as we've
// seen a leading '::' or part of a nested-name-specifier.
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ObjectType = ParsedType();
Initial implementation of a code-completion interface in Clang. In 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
2009-09-18 05:32:03 +08:00
if (Tok.is(tok::code_completion)) {
// Code completion for a nested-name-specifier, where the code
// code completion token follows the '::'.
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
Actions.CodeCompleteQualifiedId(getCurScope(), SS, EnteringContext);
Improve code completion in failure cases in two ways: 1) Suppress diagnostics as soon as we form the code-completion token, so we don't get any error/warning spew from the early end-of-file. 2) If we consume a code-completion token when we weren't expecting one, go into a code-completion recovery path that produces the best results it can based on the context that the parser is in. llvm-svn: 104585
2010-05-25 13:58:43 +08:00
ConsumeCodeCompletionToken();
Initial implementation of a code-completion interface in Clang. In 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
2009-09-18 05:32:03 +08:00
}
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
move some code around, no functionality change. llvm-svn: 74260
2009-06-26 11:47:46 +08:00
// nested-name-specifier:
// nested-name-specifier 'template'[opt] simple-template-id '::'
// Parse the optional 'template' keyword, then make sure we have
// 'identifier <' after it.
if (Tok.is(tok::kw_template)) {
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
// If we don't have a scope specifier or an object type, this isn't a
Fix a couple issues with parsing invalid nested-name-specifiers. llvm-svn: 80421
2009-08-29 12:08:08 +08:00
// nested-name-specifier, since they aren't allowed to start with
// 'template'.
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
if (!HasScopeSpecifier && !ObjectType)
Fix a couple issues with parsing invalid nested-name-specifiers. llvm-svn: 80421
2009-08-29 12:08:08 +08:00
break;
Fix speculative parsing of dependent template names in nested-name-specifiers so that they don't gobble the template name (or operator-function-id) unless there is also a template-argument-list. For example, given T::template apply we would previously consume both "template" and "apply" as part of parsing the nested-name-specifier, then error when we see that there is no "<" starting a template argument list. Now, we parse such constructs tentatively, and back off if the "<" is not present. This allows us to parse dependent template names as one would use them for, e.g., template template parameters: template<typename T, template<class> class X = T::template apply> struct MetaSomething; Also, test default arguments for template template parameters. llvm-svn: 86841
2009-11-12 00:39:34 +08:00
TentativeParsingAction TPA(*this);
move some code around, no functionality change. llvm-svn: 74260
2009-06-26 11:47:46 +08:00
SourceLocation TemplateKWLoc = ConsumeToken();
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
UnqualifiedId TemplateName;
if (Tok.is(tok::identifier)) {
// Consume the identifier.
Fix speculative parsing of dependent template names in nested-name-specifiers so that they don't gobble the template name (or operator-function-id) unless there is also a template-argument-list. For example, given T::template apply we would previously consume both "template" and "apply" as part of parsing the nested-name-specifier, then error when we see that there is no "<" starting a template argument list. Now, we parse such constructs tentatively, and back off if the "<" is not present. This allows us to parse dependent template names as one would use them for, e.g., template template parameters: template<typename T, template<class> class X = T::template apply> struct MetaSomething; Also, test default arguments for template template parameters. llvm-svn: 86841
2009-11-12 00:39:34 +08:00
TemplateName.setIdentifier(Tok.getIdentifierInfo(), Tok.getLocation());
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
ConsumeToken();
} else if (Tok.is(tok::kw_operator)) {
if (ParseUnqualifiedIdOperator(SS, EnteringContext, ObjectType,
Fix speculative parsing of dependent template names in nested-name-specifiers so that they don't gobble the template name (or operator-function-id) unless there is also a template-argument-list. For example, given T::template apply we would previously consume both "template" and "apply" as part of parsing the nested-name-specifier, then error when we see that there is no "<" starting a template argument list. Now, we parse such constructs tentatively, and back off if the "<" is not present. This allows us to parse dependent template names as one would use them for, e.g., template template parameters: template<typename T, template<class> class X = T::template apply> struct MetaSomething; Also, test default arguments for template template parameters. llvm-svn: 86841
2009-11-12 00:39:34 +08:00
TemplateName)) {
TPA.Commit();
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
break;
Fix speculative parsing of dependent template names in nested-name-specifiers so that they don't gobble the template name (or operator-function-id) unless there is also a template-argument-list. For example, given T::template apply we would previously consume both "template" and "apply" as part of parsing the nested-name-specifier, then error when we see that there is no "<" starting a template argument list. Now, we parse such constructs tentatively, and back off if the "<" is not present. This allows us to parse dependent template names as one would use them for, e.g., template template parameters: template<typename T, template<class> class X = T::template apply> struct MetaSomething; Also, test default arguments for template template parameters. llvm-svn: 86841
2009-11-12 00:39:34 +08:00
}
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
Fix test and handle IK_LiteralOperatorId in a few more places. llvm-svn: 90030
2009-11-28 16:58:14 +08:00
if (TemplateName.getKind() != UnqualifiedId::IK_OperatorFunctionId &&
TemplateName.getKind() != UnqualifiedId::IK_LiteralOperatorId) {
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
Diag(TemplateName.getSourceRange().getBegin(),
diag::err_id_after_template_in_nested_name_spec)
<< TemplateName.getSourceRange();
Fix speculative parsing of dependent template names in nested-name-specifiers so that they don't gobble the template name (or operator-function-id) unless there is also a template-argument-list. For example, given T::template apply we would previously consume both "template" and "apply" as part of parsing the nested-name-specifier, then error when we see that there is no "<" starting a template argument list. Now, we parse such constructs tentatively, and back off if the "<" is not present. This allows us to parse dependent template names as one would use them for, e.g., template template parameters: template<typename T, template<class> class X = T::template apply> struct MetaSomething; Also, test default arguments for template template parameters. llvm-svn: 86841
2009-11-12 00:39:34 +08:00
TPA.Commit();
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
break;
}
} else {
Fix speculative parsing of dependent template names in nested-name-specifiers so that they don't gobble the template name (or operator-function-id) unless there is also a template-argument-list. For example, given T::template apply we would previously consume both "template" and "apply" as part of parsing the nested-name-specifier, then error when we see that there is no "<" starting a template argument list. Now, we parse such constructs tentatively, and back off if the "<" is not present. This allows us to parse dependent template names as one would use them for, e.g., template template parameters: template<typename T, template<class> class X = T::template apply> struct MetaSomething; Also, test default arguments for template template parameters. llvm-svn: 86841
2009-11-12 00:39:34 +08:00
TPA.Revert();
move some code around, no functionality change. llvm-svn: 74260
2009-06-26 11:47:46 +08:00
break;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fix speculative parsing of dependent template names in nested-name-specifiers so that they don't gobble the template name (or operator-function-id) unless there is also a template-argument-list. For example, given T::template apply we would previously consume both "template" and "apply" as part of parsing the nested-name-specifier, then error when we see that there is no "<" starting a template argument list. Now, we parse such constructs tentatively, and back off if the "<" is not present. This allows us to parse dependent template names as one would use them for, e.g., template template parameters: template<typename T, template<class> class X = T::template apply> struct MetaSomething; Also, test default arguments for template template parameters. llvm-svn: 86841
2009-11-12 00:39:34 +08:00
// If the next token is not '<', we have a qualified-id that refers
// to a template name, such as T::template apply, but is not a
// template-id.
if (Tok.isNot(tok::less)) {
TPA.Revert();
break;
}
// Commit to parsing the template-id.
TPA.Commit();
When we see a 'template' disambiguator that marks the next identifier (or operator-function-id) as a template, but the context is actually non-dependent or the current instantiation, allow us to use knowledge of what kind of template it is, e.g., type template vs. function template, for further syntactic disambiguation. This allows us to parse properly in the presence of stray "template" keywords, which is necessary in C++0x and it's good recovery in C++98/03. llvm-svn: 106167
2010-06-17 07:00:59 +08:00
TemplateTy Template;
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
if (TemplateNameKind TNK = Actions.ActOnDependentTemplateName(getCurScope(),
When we see a 'template' disambiguator that marks the next identifier (or operator-function-id) as a template, but the context is actually non-dependent or the current instantiation, allow us to use knowledge of what kind of template it is, e.g., type template vs. function template, for further syntactic disambiguation. This allows us to parse properly in the presence of stray "template" keywords, which is necessary in C++0x and it's good recovery in C++98/03. llvm-svn: 106167
2010-06-17 07:00:59 +08:00
TemplateKWLoc,
SS,
TemplateName,
ObjectType,
EnteringContext,
Template)) {
if (AnnotateTemplateIdToken(Template, TNK, &SS, TemplateName,
TemplateKWLoc, false))
return true;
} else
Fix an assertion-on-error during tentative constructor parsing by propagating error conditions out of the various annotate-me-a-snowflake routines. Generally (but not universally) removes redundant diagnostics as well as, you know, not crashing on bad code. On the other hand, I have just signed myself up to fix fiddly parser errors for the next week. Again. llvm-svn: 97221
2010-02-26 16:45:28 +08:00
return true;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
move some code around, no functionality change. llvm-svn: 74260
2009-06-26 11:47:46 +08:00
continue;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
if (Tok.is(tok::annot_template_id) && NextToken().is(tok::coloncolon)) {
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// We have
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
//
// simple-template-id '::'
//
// So we need to check whether the simple-template-id is of the
Parsing and AST representation for dependent template names that occur within nested-name-specifiers, e.g., for the "apply" in typename MetaFun::template apply<T1, T2>::type At present, we can't instantiate these nested-name-specifiers, so our testing is sketchy. llvm-svn: 68081
2009-03-31 08:43:58 +08:00
// right kind (it should name a type or be dependent), and then
// convert it into a type within the nested-name-specifier.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
TemplateIdAnnotation *TemplateId
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
= static_cast<TemplateIdAnnotation *>(Tok.getAnnotationValue());
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
if (CheckForDestructor && GetLookAheadToken(2).is(tok::tilde)) {
*MayBePseudoDestructor = true;
Fix an assertion-on-error during tentative constructor parsing by propagating error conditions out of the various annotate-me-a-snowflake routines. Generally (but not universally) removes redundant diagnostics as well as, you know, not crashing on bad code. On the other hand, I have just signed myself up to fix fiddly parser errors for the next week. Again. llvm-svn: 97221
2010-02-26 16:45:28 +08:00
return false;
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
if (TemplateId->Kind == TNK_Type_template ||
Parsing and AST representation for dependent template names that occur within nested-name-specifiers, e.g., for the "apply" in typename MetaFun::template apply<T1, T2>::type At present, we can't instantiate these nested-name-specifiers, so our testing is sketchy. llvm-svn: 68081
2009-03-31 08:43:58 +08:00
TemplateId->Kind == TNK_Dependent_template_name) {
Make parsing a semantic analysis a little more robust following Sema failures that involve malformed types, e.g., "typename X::foo" where "foo" isn't a type, or "std::vector<void>" that doens't instantiate properly. Similarly, be a bit smarter in our handling of ambiguities that occur in Sema::getTypeName, to eliminate duplicate error messages about ambiguous name lookup. This eliminates two XFAILs in test/SemaCXX, one of which was crying out to us, trying to tell us that we were producing repeated error messages. llvm-svn: 68251
2009-04-02 05:51:26 +08:00
AnnotateTemplateIdTokenAsType(&SS);
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
assert(Tok.is(tok::annot_typename) &&
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
"AnnotateTemplateIdTokenAsType isn't working");
Token TypeToken = Tok;
ConsumeToken();
assert(Tok.is(tok::coloncolon) && "NextToken() not working properly!");
SourceLocation CCLoc = ConsumeToken();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
if (!HasScopeSpecifier) {
SS.setBeginLoc(TypeToken.getLocation());
HasScopeSpecifier = true;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
if (ParsedType T = getTypeAnnotation(TypeToken)) {
CXXScopeTy *Scope =
Actions.ActOnCXXNestedNameSpecifier(getCurScope(), SS, T,
Make parsing a semantic analysis a little more robust following Sema failures that involve malformed types, e.g., "typename X::foo" where "foo" isn't a type, or "std::vector<void>" that doens't instantiate properly. Similarly, be a bit smarter in our handling of ambiguities that occur in Sema::getTypeName, to eliminate duplicate error messages about ambiguous name lookup. This eliminates two XFAILs in test/SemaCXX, one of which was crying out to us, trying to tell us that we were producing repeated error messages. llvm-svn: 68251
2009-04-02 05:51:26 +08:00
TypeToken.getAnnotationRange(),
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
CCLoc);
SS.setScopeRep(Scope);
} else
Make parsing a semantic analysis a little more robust following Sema failures that involve malformed types, e.g., "typename X::foo" where "foo" isn't a type, or "std::vector<void>" that doens't instantiate properly. Similarly, be a bit smarter in our handling of ambiguities that occur in Sema::getTypeName, to eliminate duplicate error messages about ambiguous name lookup. This eliminates two XFAILs in test/SemaCXX, one of which was crying out to us, trying to tell us that we were producing repeated error messages. llvm-svn: 68251
2009-04-02 05:51:26 +08:00
SS.setScopeRep(0);
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
SS.setEndLoc(CCLoc);
continue;
simplify some code. llvm-svn: 74259
2009-06-26 11:45:46 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
simplify some code. llvm-svn: 74259
2009-06-26 11:45:46 +08:00
assert(false && "FIXME: Only type template names supported here");
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
}
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
// The rest of the nested-name-specifier possibilities start with
// tok::identifier.
if (Tok.isNot(tok::identifier))
break;
IdentifierInfo &II = *Tok.getIdentifierInfo();
// nested-name-specifier:
// type-name '::'
// namespace-name '::'
// nested-name-specifier identifier '::'
Token Next = NextToken();
reapply my patch for PR4451, which improves diagnostics for :: vs : confusion. This time with a fix to bail out when in a dependent context. llvm-svn: 90730
2009-12-07 09:36:53 +08:00
// If we get foo:bar, this is almost certainly a typo for foo::bar. Recover
// and emit a fixit hint for it.
Implement support for parsing pseudo-destructor expression with a nested-name-specifier, e.g., typedef int Int; int *p; p->Int::~Int(); This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression. llvm-svn: 96743
2010-02-22 02:36:56 +08:00
if (Next.is(tok::colon) && !ColonIsSacred) {
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
if (Actions.IsInvalidUnlessNestedName(getCurScope(), SS, II, ObjectType,
Implement support for parsing pseudo-destructor expression with a nested-name-specifier, e.g., typedef int Int; int *p; p->Int::~Int(); This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression. llvm-svn: 96743
2010-02-22 02:36:56 +08:00
EnteringContext) &&
// If the token after the colon isn't an identifier, it's still an
// error, but they probably meant something else strange so don't
// recover like this.
PP.LookAhead(1).is(tok::identifier)) {
Diag(Next, diag::err_unexected_colon_in_nested_name_spec)
Reinstate my CodeModificationHint -> FixItHint renaming patch, without the C-only "optimization". llvm-svn: 100022
2010-04-01 01:46:05 +08:00
<< FixItHint::CreateReplacement(Next.getLocation(), "::");
Implement support for parsing pseudo-destructor expression with a nested-name-specifier, e.g., typedef int Int; int *p; p->Int::~Int(); This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression. llvm-svn: 96743
2010-02-22 02:36:56 +08:00
// Recover as if the user wrote '::'.
Next.setKind(tok::coloncolon);
}
reapply my patch for PR4451, which improves diagnostics for :: vs : confusion. This time with a fix to bail out when in a dependent context. llvm-svn: 90730
2009-12-07 09:36:53 +08:00
}
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
if (Next.is(tok::coloncolon)) {
ActOnPseudoDestructorExpr now performs all semantic analysis for pseudo-destructor expressions, and builds the CXXPseudoDestructorExpr node directly. Currently, this only affects pseudo-destructor expressions when they are parsed, but not after template instantiation. That's coming next... Improve parsing of pseudo-destructor-names. When parsing the nested-name-specifier and we hit the sequence of tokens X :: ~, query the actual module to determine whether X is a type-name (in which case the X :: is part of the pseudo-destructor-name but not the nested-name-specifier) or not (in which case the X :: is part of the nested-name-specifier). llvm-svn: 97058
2010-02-25 05:29:12 +08:00
if (CheckForDestructor && GetLookAheadToken(2).is(tok::tilde) &&
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
!Actions.isNonTypeNestedNameSpecifier(getCurScope(), SS, Tok.getLocation(),
ActOnPseudoDestructorExpr now performs all semantic analysis for pseudo-destructor expressions, and builds the CXXPseudoDestructorExpr node directly. Currently, this only affects pseudo-destructor expressions when they are parsed, but not after template instantiation. That's coming next... Improve parsing of pseudo-destructor-names. When parsing the nested-name-specifier and we hit the sequence of tokens X :: ~, query the actual module to determine whether X is a type-name (in which case the X :: is part of the pseudo-destructor-name but not the nested-name-specifier) or not (in which case the X :: is part of the nested-name-specifier). llvm-svn: 97058
2010-02-25 05:29:12 +08:00
II, ObjectType)) {
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
*MayBePseudoDestructor = true;
Fix an assertion-on-error during tentative constructor parsing by propagating error conditions out of the various annotate-me-a-snowflake routines. Generally (but not universally) removes redundant diagnostics as well as, you know, not crashing on bad code. On the other hand, I have just signed myself up to fix fiddly parser errors for the next week. Again. llvm-svn: 97221
2010-02-26 16:45:28 +08:00
return false;
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
}
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
// We have an identifier followed by a '::'. Lookup this name
// as the name in a nested-name-specifier.
SourceLocation IdLoc = ConsumeToken();
reapply my patch for PR4451, which improves diagnostics for :: vs : confusion. This time with a fix to bail out when in a dependent context. llvm-svn: 90730
2009-12-07 09:36:53 +08:00
assert((Tok.is(tok::coloncolon) || Tok.is(tok::colon)) &&
"NextToken() not working properly!");
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
SourceLocation CCLoc = ConsumeToken();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
if (!HasScopeSpecifier) {
SS.setBeginLoc(IdLoc);
HasScopeSpecifier = true;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Fix PR7180. For void f( a::b::c ); we would cache the tokens "a::b::" but then we would try to annotate them using the range "a::". Before annotating them with the (invalid) C++ scope spec, set it to the range of "a::b::". llvm-svn: 106536
2010-06-22 19:30:04 +08:00
if (!SS.isInvalid())
SS.setScopeRep(
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
Actions.ActOnCXXNestedNameSpecifier(getCurScope(), SS, IdLoc, CCLoc, II,
Fix PR7180. For void f( a::b::c ); we would cache the tokens "a::b::" but then we would try to annotate them using the range "a::". Before annotating them with the (invalid) C++ scope spec, set it to the range of "a::b::". llvm-svn: 106536
2010-06-22 19:30:04 +08:00
ObjectType, EnteringContext));
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
SS.setEndLoc(CCLoc);
continue;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
// nested-name-specifier:
// type-name '<'
if (Next.is(tok::less)) {
TemplateTy Template;
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
UnqualifiedId TemplateName;
TemplateName.setIdentifier(&II, Tok.getLocation());
Improve parser recovery when we encounter a dependent template name that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
2010-05-22 07:18:07 +08:00
bool MemberOfUnknownSpecialization;
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
if (TemplateNameKind TNK = Actions.isTemplateName(getCurScope(), SS,
Template keyword should not be ignored building a QualifiedTemplateName. llvm-svn: 110441
2010-08-06 20:11:11 +08:00
/*hasTemplateKeyword=*/false,
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
TemplateName,
Rewrite of our handling of name lookup in C++ member access expressions, e.g., 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
2009-09-03 06:59:36 +08:00
ObjectType,
Improve support for out-of-line definitions of nested templates and 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
2009-08-26 06:51:20 +08:00
EnteringContext,
Improve parser recovery when we encounter a dependent template name that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
2010-05-22 07:18:07 +08:00
Template,
MemberOfUnknownSpecialization)) {
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
// We have found a template name, so annotate this this token
// with a template-id annotation. We do not permit the
// template-id to be translated into a type annotation,
// because some clients (e.g., the parsing of class template
// specializations) still want to see the original template-id
// token.
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
ConsumeToken();
if (AnnotateTemplateIdToken(Template, TNK, &SS, TemplateName,
SourceLocation(), false))
Fix an assertion-on-error during tentative constructor parsing by propagating error conditions out of the various annotate-me-a-snowflake routines. Generally (but not universally) removes redundant diagnostics as well as, you know, not crashing on bad code. On the other hand, I have just signed myself up to fix fiddly parser errors for the next week. Again. llvm-svn: 97221
2010-02-26 16:45:28 +08:00
return true;
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
continue;
Improve recovery when we see a dependent template name that is missing the required "template" keyword, using the same heuristics we do for dependent template names in member access expressions, e.g., test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template' keyword to treat 'getAs' as a dependent template name T::getAs<U>(); ^ template Fixes PR5404. llvm-svn: 104409
2010-05-22 07:43:39 +08:00
}
if (MemberOfUnknownSpecialization && (ObjectType || SS.isSet()) &&
IsTemplateArgumentList(1)) {
// We have something like t::getAs<T>, where getAs is a
// member of an unknown specialization. However, this will only
// parse correctly as a template, so suggest the keyword 'template'
// before 'getAs' and treat this as a dependent template name.
Diag(Tok.getLocation(), diag::err_missing_dependent_template_keyword)
<< II.getName()
<< FixItHint::CreateInsertion(Tok.getLocation(), "template ");
When we see a 'template' disambiguator that marks the next identifier (or operator-function-id) as a template, but the context is actually non-dependent or the current instantiation, allow us to use knowledge of what kind of template it is, e.g., type template vs. function template, for further syntactic disambiguation. This allows us to parse properly in the presence of stray "template" keywords, which is necessary in C++0x and it's good recovery in C++98/03. llvm-svn: 106167
2010-06-17 07:00:59 +08:00
if (TemplateNameKind TNK
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
= Actions.ActOnDependentTemplateName(getCurScope(),
When we see a 'template' disambiguator that marks the next identifier (or operator-function-id) as a template, but the context is actually non-dependent or the current instantiation, allow us to use knowledge of what kind of template it is, e.g., type template vs. function template, for further syntactic disambiguation. This allows us to parse properly in the presence of stray "template" keywords, which is necessary in C++0x and it's good recovery in C++98/03. llvm-svn: 106167
2010-06-17 07:00:59 +08:00
Tok.getLocation(), SS,
TemplateName, ObjectType,
EnteringContext, Template)) {
// Consume the identifier.
ConsumeToken();
if (AnnotateTemplateIdToken(Template, TNK, &SS, TemplateName,
SourceLocation(), false))
return true;
}
else
Improve recovery when we see a dependent template name that is missing the required "template" keyword, using the same heuristics we do for dependent template names in member access expressions, e.g., test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template' keyword to treat 'getAs' as a dependent template name T::getAs<U>(); ^ template Fixes PR5404. llvm-svn: 104409
2010-05-22 07:43:39 +08:00
return true;
When we see a 'template' disambiguator that marks the next identifier (or operator-function-id) as a template, but the context is actually non-dependent or the current instantiation, allow us to use knowledge of what kind of template it is, e.g., type template vs. function template, for further syntactic disambiguation. This allows us to parse properly in the presence of stray "template" keywords, which is necessary in C++0x and it's good recovery in C++98/03. llvm-svn: 106167
2010-06-17 07:00:59 +08:00
Improve recovery when we see a dependent template name that is missing the required "template" keyword, using the same heuristics we do for dependent template names in member access expressions, e.g., test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template' keyword to treat 'getAs' as a dependent template name T::getAs<U>(); ^ template Fixes PR5404. llvm-svn: 104409
2010-05-22 07:43:39 +08:00
continue;
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
}
}
Implement parsing of nested-name-specifiers that involve template-ids, e.g., std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
2009-02-26 03:37:18 +08:00
// We don't have any tokens that form the beginning of a
// nested-name-specifier, so we're done.
break;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
// Even if we didn't see any pieces of a nested-name-specifier, we
// still check whether there is a tilde in this position, which
// indicates a potential pseudo-destructor.
if (CheckForDestructor && Tok.is(tok::tilde))
*MayBePseudoDestructor = true;
Fix an assertion-on-error during tentative constructor parsing by propagating error conditions out of the various annotate-me-a-snowflake routines. Generally (but not universally) removes redundant diagnostics as well as, you know, not crashing on bad code. On the other hand, I have just signed myself up to fix fiddly parser errors for the next week. Again. llvm-svn: 97221
2010-02-26 16:45:28 +08:00
return false;
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
}
/// ParseCXXIdExpression - Handle id-expression.
///
/// id-expression:
/// unqualified-id
/// qualified-id
///
/// qualified-id:
/// '::'[opt] nested-name-specifier 'template'[opt] unqualified-id
/// '::' identifier
/// '::' operator-function-id
Preliminary parsing and ASTs for template-ids that refer to function templates, such as make<int&>. These template-ids are only barely functional for function calls; much more to come. llvm-svn: 74563
2009-07-01 06:34:41 +08:00
/// '::' template-id
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
///
/// NOTE: The standard specifies that, for qualified-id, the parser does not
/// expect:
///
/// '::' conversion-function-id
/// '::' '~' class-name
///
/// This may cause a slight inconsistency on diagnostics:
///
/// class C {};
/// namespace A {}
/// void f() {
/// :: A :: ~ C(); // Some Sema error about using destructor with a
/// // namespace.
/// :: ~ C(); // Some Parser error like 'unexpected ~'.
/// }
///
/// We simplify the parser a bit and make it work like:
///
/// qualified-id:
/// '::'[opt] nested-name-specifier 'template'[opt] unqualified-id
/// '::' unqualified-id
///
/// That way Sema can handle and report similar errors for namespaces and the
/// global scope.
///
Allow taking the address of data members, resulting in a member pointer. Pointers to functions don't work yet, and pointers to overloaded functions even less. Also, far too much illegal code is accepted. llvm-svn: 63655
2009-02-04 04:19:35 +08:00
/// The isAddressOfOperand parameter indicates that this id-expression is a
/// direct operand of the address-of operator. This is, besides member contexts,
/// the only place where a qualified-id naming a non-static class member may
/// appear.
///
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Parser::ParseCXXIdExpression(bool isAddressOfOperand) {
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
// qualified-id:
// '::'[opt] nested-name-specifier 'template'[opt] unqualified-id
// '::' unqualified-id
//
CXXScopeSpec SS;
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ParseOptionalCXXScopeSpecifier(SS, ParsedType(), false);
Use ParseUnqualifiedId when parsing id-expressions. This eliminates 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
2009-11-04 00:56:39 +08:00
UnqualifiedId Name;
if (ParseUnqualifiedId(SS,
/*EnteringContext=*/false,
/*AllowDestructorName=*/false,
/*AllowConstructorName=*/false,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
/*ObjectType=*/ ParsedType(),
Use ParseUnqualifiedId when parsing id-expressions. This eliminates 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
2009-11-04 00:56:39 +08:00
Name))
return ExprError();
If a C++ qualified id is followed by a postfix suffix, it is never the direct operand of an addressof operator, and so we should not treat it as an abstract member-pointer expression and therefore suppress the implicit member access. This is really a well-formedness constraint on expressions: a DeclRefExpr of a FieldDecl or a non-static CXXMethodDecl (or template thereof, or unresolved collection thereof) should not be allowed in an arbitrary location in the AST. Arguably it shouldn't be allowed anywhere and we should have a different expr node type for this. But unfortunately we don't have a good way of enforcing this kind of constraint right now. llvm-svn: 89578
2009-11-22 10:49:43 +08:00
// This is only the direct operand of an & operator if it is not
// followed by a postfix-expression suffix.
Propagate whether an id-expression is the immediate argument of an '&' expression from the second caller of ActOnIdExpression. Teach template argument deduction that an overloaded id-expression doesn't give a valid type for deduction purposes to a non-static member function unless the expression has the correct syntactic form. Teach ActOnIdExpression that it shouldn't try to create implicit member expressions for '&function', because this isn't a permitted form of use for member functions. Teach CheckAddressOfOperand to diagnose these more carefully. Some of these cases aren't reachable right now because earlier diagnostics interrupt them. llvm-svn: 112258
2010-08-27 17:08:28 +08:00
if (isAddressOfOperand && isPostfixExpressionSuffixStart())
isAddressOfOperand = false;
Use ParseUnqualifiedId when parsing id-expressions. This eliminates 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
2009-11-04 00:56:39 +08:00
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
return Actions.ActOnIdExpression(getCurScope(), SS, Name, Tok.is(tok::l_paren),
Use ParseUnqualifiedId when parsing id-expressions. This eliminates 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
2009-11-04 00:56:39 +08:00
isAddressOfOperand);
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
}
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
/// ParseCXXCasts - This handles the various ways to cast expressions to another
/// type.
///
/// postfix-expression: [C++ 5.2p1]
/// 'dynamic_cast' '<' type-name '>' '(' expression ')'
/// 'static_cast' '<' type-name '>' '(' expression ')'
/// 'reinterpret_cast' '<' type-name '>' '(' expression ')'
/// 'const_cast' '<' type-name '>' '(' expression ')'
///
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Parser::ParseCXXCasts() {
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
tok::TokenKind Kind = Tok.getKind();
const char *CastName = 0; // For error messages
switch (Kind) {
default: assert(0 && "Unknown C++ cast!"); abort();
case tok::kw_const_cast: CastName = "const_cast"; break;
case tok::kw_dynamic_cast: CastName = "dynamic_cast"; break;
case tok::kw_reinterpret_cast: CastName = "reinterpret_cast"; break;
case tok::kw_static_cast: CastName = "static_cast"; break;
}
SourceLocation OpLoc = ConsumeToken();
SourceLocation LAngleBracketLoc = Tok.getLocation();
if (ExpectAndConsume(tok::less, diag::err_expected_less_after, CastName))
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError();
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
Update Parser::ParseTypeName to return a TypeResult, which also tells us whether there was an error in trying to parse a type-name (type-id in C++). This allows propagation of errors further in the compiler, suppressing more bogus error messages. llvm-svn: 64922
2009-02-19 01:45:20 +08:00
TypeResult CastTy = ParseTypeName();
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
SourceLocation RAngleBracketLoc = Tok.getLocation();
Change a couple of the Parser::Diag methods to return DiagnosticInfo and let the clients push whatever they want into the DiagnosticInfo instead of hard coding a few forms. Also switch various clients to use Diag(Tok, ...) instead of Diag(Tok.getLocation(), ...) as the canonical form to simplify the code a bit. llvm-svn: 59509
2008-11-18 15:48:38 +08:00
if (ExpectAndConsume(tok::greater, diag::err_expected_greater))
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError(Diag(LAngleBracketLoc, diag::note_matching) << "<");
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
SourceLocation LParenLoc = Tok.getLocation(), RParenLoc;
Remove ParseSimpleParenExpression. Embed its functionality into it's only user, ParseCXXCasts. CXXCasts now get the "actual" expression directly, they no longer always receive a ParenExpr. This is better since the parentheses are always part of the C++ casts syntax. llvm-svn: 72257
2009-05-22 18:23:16 +08:00
if (ExpectAndConsume(tok::l_paren, diag::err_expected_lparen_after, CastName))
return ExprError();
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Result = ParseExpression();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Remove ParseSimpleParenExpression. Embed its functionality into it's only user, ParseCXXCasts. CXXCasts now get the "actual" expression directly, they no longer always receive a ParenExpr. This is better since the parentheses are always part of the C++ casts syntax. llvm-svn: 72257
2009-05-22 18:23:16 +08:00
// Match the ')'.
Improve recovery when we fail to parse the operand of a C++ named cast. Fixes PR5210 llvm-svn: 86234
2009-11-06 13:48:00 +08:00
RParenLoc = MatchRHSPunctuation(tok::r_paren, LParenLoc);
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
Update Parser::ParseTypeName to return a TypeResult, which also tells us whether there was an error in trying to parse a type-name (type-id in C++). This allows propagation of errors further in the compiler, suppressing more bogus error messages. llvm-svn: 64922
2009-02-19 01:45:20 +08:00
if (!Result.isInvalid() && !CastTy.isInvalid())
Refactor the expression class hierarchy for casts. Most importantly: - CastExpr is the root of all casts - ImplicitCastExpr is (still) used for all explicit casts - ExplicitCastExpr is now the root of all *explicit* casts - ExplicitCCastExpr (new name needed!?) is a C-style cast in C or C++ - CXXFunctionalCastExpr inherits from ExplicitCastExpr - CXXNamedCastExpr inherits from ExplicitCastExpr and is the root of all of the C++ named cast expression types (static_cast, dynamic_cast, etc.) - Added classes CXXStaticCastExpr, CXXDynamicCastExpr, CXXReinterpretCastExpr, and CXXConstCastExpr to Also, fixed returned-stack-addr.cpp, which broke once when we fixed reinterpret_cast to diagnose double->int* conversions and again when we eliminated implicit conversions to reference types. The fix is in both testcase and SemaChecking.cpp. Most of this patch is simply support for the renaming. There's very little actual change in semantics. llvm-svn: 58264
2008-10-28 03:41:14 +08:00
Result = Actions.ActOnCXXNamedCast(OpLoc, Kind,
Convert a bunch of actions to smart pointers, and also bring PrintParserCallbacks a bit more in line with reality. llvm-svn: 67029
2009-03-16 01:47:39 +08:00
LAngleBracketLoc, CastTy.get(),
Update Parser::ParseTypeName to return a TypeResult, which also tells us whether there was an error in trying to parse a type-name (type-id in C++). This allows propagation of errors further in the compiler, suppressing more bogus error messages. llvm-svn: 64922
2009-02-19 01:45:20 +08:00
RAngleBracketLoc,
Kill off ExprArg (now just Expr*) and StmtArg (now just Stmt*). llvm-svn: 111863
2010-08-24 07:25:46 +08:00
LParenLoc, Result.take(), RParenLoc);
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return move(Result);
Add support for parsing and pretty printing const_cast, dynamic_cast, reinterpret_cast, and static_cast. Patch by Bill! llvm-svn: 39247
2006-12-05 02:06:35 +08:00
}
C++: Added support for bool types. llvm-svn: 39338
2007-02-13 09:51:42 +08:00
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
/// ParseCXXTypeid - This handles the C++ typeid expression.
///
/// postfix-expression: [C++ 5.2p1]
/// 'typeid' '(' expression ')'
/// 'typeid' '(' type-id ')'
///
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Parser::ParseCXXTypeid() {
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
assert(Tok.is(tok::kw_typeid) && "Not 'typeid'!");
SourceLocation OpLoc = ConsumeToken();
SourceLocation LParenLoc = Tok.getLocation();
SourceLocation RParenLoc;
// typeid expressions are always parenthesized.
if (ExpectAndConsume(tok::l_paren, diag::err_expected_lparen_after,
"typeid"))
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError();
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Result;
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
if (isTypeIdInParens()) {
Update Parser::ParseTypeName to return a TypeResult, which also tells us whether there was an error in trying to parse a type-name (type-id in C++). This allows propagation of errors further in the compiler, suppressing more bogus error messages. llvm-svn: 64922
2009-02-19 01:45:20 +08:00
TypeResult Ty = ParseTypeName();
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
// Match the ')'.
Fix a few minor issues with parsing and semantic analysis of C++ typeid expressions: - make sure we have a proper source location for the closing ')' - cache the declaration of std::type_info once we've found it llvm-svn: 113441
2010-09-09 07:14:30 +08:00
RParenLoc = MatchRHSPunctuation(tok::r_paren, LParenLoc);
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
Fix a few minor issues with parsing and semantic analysis of C++ typeid expressions: - make sure we have a proper source location for the closing ')' - cache the declaration of std::type_info once we've found it llvm-svn: 113441
2010-09-09 07:14:30 +08:00
if (Ty.isInvalid() || RParenLoc.isInvalid())
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError();
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
Result = Actions.ActOnCXXTypeid(OpLoc, LParenLoc, /*isType=*/true,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
Ty.get().getAsOpaquePtr(), RParenLoc);
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
} else {
Keep track of when declarations are "used" according to C and C++. This logic is required to trigger implicit instantiation of function templates and member functions of class templates, which will be implemented separately. This commit includes support for -Wunused-parameter, printing warnings for named parameters that are not used within a function/Objective-C method/block. Fixes <rdar://problem/6505209>. llvm-svn: 73797
2009-06-20 07:52:42 +08:00
// C++0x [expr.typeid]p3:
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// When typeid is applied to an expression other than an lvalue of a
// polymorphic class type [...] The expression is an unevaluated
Keep track of when declarations are "used" according to C and C++. This logic is required to trigger implicit instantiation of function templates and member functions of class templates, which will be implemented separately. This commit includes support for -Wunused-parameter, printing warnings for named parameters that are not used within a function/Objective-C method/block. Fixes <rdar://problem/6505209>. llvm-svn: 73797
2009-06-20 07:52:42 +08:00
// operand (Clause 5).
//
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// Note that we can't tell whether the expression is an lvalue of a
Keep track of when declarations are "used" according to C and C++. This logic is required to trigger implicit instantiation of function templates and member functions of class templates, which will be implemented separately. This commit includes support for -Wunused-parameter, printing warnings for named parameters that are not used within a function/Objective-C method/block. Fixes <rdar://problem/6505209>. llvm-svn: 73797
2009-06-20 07:52:42 +08:00
// polymorphic class type until after we've parsed the expression, so
Rework the way we track which declarations are "used" during compilation, and (hopefully) introduce RAII objects for changing the "potentially evaluated" state at all of the necessary places within Sema and Parser. Other changes: - Set the unevaluated/potentially-evaluated context appropriately during template instantiation. - We now recognize three different states while parsing or instantiating expressions: unevaluated, potentially evaluated, and potentially potentially evaluated (for C++'s typeid). - When we're in a potentially potentially-evaluated context, queue up MarkDeclarationReferenced calls in a stack. For C++ typeid expressions that are potentially evaluated, we will play back these MarkDeclarationReferenced calls when we exit the corresponding potentially potentially-evaluated context. - Non-type template arguments are now parsed as constant expressions, so they are not potentially-evaluated. llvm-svn: 73899
2009-06-23 04:57:11 +08:00
// we the expression is potentially potentially evaluated.
EnterExpressionEvaluationContext Unevaluated(Actions,
One who seeks knowledge learns something new every day. One who seeks the Tao unlearns something new every day. Less and less remains until you arrive at non-action. When you arrive at non-action, nothing will be left undone. llvm-svn: 112244
2010-08-27 07:41:50 +08:00
Sema::PotentiallyPotentiallyEvaluated);
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
Result = ParseExpression();
// Match the ')'.
Consistently use smart pointers for stmt and expr nodes in parser local variables. llvm-svn: 60761
2008-12-09 21:15:23 +08:00
if (Result.isInvalid())
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
SkipUntil(tok::r_paren);
else {
Fix a few minor issues with parsing and semantic analysis of C++ typeid expressions: - make sure we have a proper source location for the closing ')' - cache the declaration of std::type_info once we've found it llvm-svn: 113441
2010-09-09 07:14:30 +08:00
RParenLoc = MatchRHSPunctuation(tok::r_paren, LParenLoc);
if (RParenLoc.isInvalid())
return ExprError();
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
Result = Actions.ActOnCXXTypeid(OpLoc, LParenLoc, /*isType=*/false,
Modify the move emulation according to the excellent design of Howard Hinnant. Makes for much nicer syntax when smart pointers are used consistently. Also, start converting internal argument passing of Parser to smart pointers. llvm-svn: 60809
2008-12-10 08:02:53 +08:00
Result.release(), RParenLoc);
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
}
}
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return move(Result);
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
}
Microsoft's __uuidof operator implementation part 1. llvm-svn: 113356
2010-09-08 20:20:18 +08:00
/// ParseCXXUuidof - This handles the Microsoft C++ __uuidof expression.
///
/// '__uuidof' '(' expression ')'
/// '__uuidof' '(' type-id ')'
///
ExprResult Parser::ParseCXXUuidof() {
assert(Tok.is(tok::kw___uuidof) && "Not '__uuidof'!");
SourceLocation OpLoc = ConsumeToken();
SourceLocation LParenLoc = Tok.getLocation();
SourceLocation RParenLoc;
// __uuidof expressions are always parenthesized.
if (ExpectAndConsume(tok::l_paren, diag::err_expected_lparen_after,
"__uuidof"))
return ExprError();
ExprResult Result;
if (isTypeIdInParens()) {
TypeResult Ty = ParseTypeName();
// Match the ')'.
RParenLoc = MatchRHSPunctuation(tok::r_paren, LParenLoc);
if (Ty.isInvalid())
return ExprError();
Result = Actions.ActOnCXXUuidof(OpLoc, LParenLoc, /*isType=*/true,
Ty.get().getAsOpaquePtr(), RParenLoc);
} else {
EnterExpressionEvaluationContext Unevaluated(Actions, Sema::Unevaluated);
Result = ParseExpression();
// Match the ')'.
if (Result.isInvalid())
SkipUntil(tok::r_paren);
else {
RParenLoc = MatchRHSPunctuation(tok::r_paren, LParenLoc);
Result = Actions.ActOnCXXUuidof(OpLoc, LParenLoc, /*isType=*/false,
Result.release(), RParenLoc);
}
}
return move(Result);
}
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
/// \brief Parse a C++ pseudo-destructor expression after the base,
/// . or -> operator, and nested-name-specifier have already been
/// parsed.
///
/// postfix-expression: [C++ 5.2]
/// postfix-expression . pseudo-destructor-name
/// postfix-expression -> pseudo-destructor-name
///
/// pseudo-destructor-name:
/// ::[opt] nested-name-specifier[opt] type-name :: ~type-name
/// ::[opt] nested-name-specifier template simple-template-id ::
/// ~type-name
/// ::[opt] nested-name-specifier[opt] ~type-name
///
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
Parser::ParseCXXPseudoDestructor(ExprArg Base, SourceLocation OpLoc,
tok::TokenKind OpKind,
CXXScopeSpec &SS,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ParsedType ObjectType) {
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
// We're parsing either a pseudo-destructor-name or a dependent
// member access that has the same form as a
// pseudo-destructor-name. We parse both in the same way and let
// the action model sort them out.
//
// Note that the ::[opt] nested-name-specifier[opt] has already
// been parsed, and if there was a simple-template-id, it has
// been coalesced into a template-id annotation token.
UnqualifiedId FirstTypeName;
SourceLocation CCLoc;
if (Tok.is(tok::identifier)) {
FirstTypeName.setIdentifier(Tok.getIdentifierInfo(), Tok.getLocation());
ConsumeToken();
assert(Tok.is(tok::coloncolon) &&"ParseOptionalCXXScopeSpecifier fail");
CCLoc = ConsumeToken();
} else if (Tok.is(tok::annot_template_id)) {
FirstTypeName.setTemplateId(
(TemplateIdAnnotation *)Tok.getAnnotationValue());
ConsumeToken();
assert(Tok.is(tok::coloncolon) &&"ParseOptionalCXXScopeSpecifier fail");
CCLoc = ConsumeToken();
} else {
FirstTypeName.setIdentifier(0, SourceLocation());
}
// Parse the tilde.
assert(Tok.is(tok::tilde) && "ParseOptionalCXXScopeSpecifier fail");
SourceLocation TildeLoc = ConsumeToken();
if (!Tok.is(tok::identifier)) {
Diag(Tok, diag::err_destructor_tilde_identifier);
return ExprError();
}
// Parse the second type.
UnqualifiedId SecondTypeName;
IdentifierInfo *Name = Tok.getIdentifierInfo();
SourceLocation NameLoc = ConsumeToken();
SecondTypeName.setIdentifier(Name, NameLoc);
// If there is a '<', the second type name is a template-id. Parse
// it as such.
if (Tok.is(tok::less) &&
ParseUnqualifiedIdTemplateId(SS, Name, NameLoc, false, ObjectType,
Support for 'template' as a disambiguator (PR7030) ParseOptionalCXXScopeSpecifier() only annotates the subset of template-ids which are not subject to lexical ambiguity. Add support for the more general case in ParseUnqualifiedId() to handle cases such as A::template B(). Also improve some diagnostic locations. Fixes PR7030, from Alp Toker! llvm-svn: 103081
2010-05-05 13:58:24 +08:00
SecondTypeName, /*AssumeTemplateName=*/true,
/*TemplateKWLoc*/SourceLocation()))
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
return ExprError();
Kill off ExprArg (now just Expr*) and StmtArg (now just Stmt*). llvm-svn: 111863
2010-08-24 07:25:46 +08:00
return Actions.ActOnPseudoDestructorExpr(getCurScope(), Base,
OpLoc, OpKind,
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
SS, FirstTypeName, CCLoc,
TildeLoc, SecondTypeName,
Tok.is(tok::l_paren));
}
C++: Added support for bool types. llvm-svn: 39338
2007-02-13 09:51:42 +08:00
/// ParseCXXBoolLiteral - This handles the C++ Boolean literals.
///
/// boolean-literal: [C++ 2.13.5]
/// 'true'
/// 'false'
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Parser::ParseCXXBoolLiteral() {
C++: Added support for bool types. llvm-svn: 39338
2007-02-13 09:51:42 +08:00
tok::TokenKind Kind = Tok.getKind();
Convert a bunch of actions to smart pointers, and also bring PrintParserCallbacks a bit more in line with reality. llvm-svn: 67029
2009-03-16 01:47:39 +08:00
return Actions.ActOnCXXBoolLiteral(ConsumeToken(), Kind);
C++: Added support for bool types. llvm-svn: 39338
2007-02-13 09:51:42 +08:00
}
add parsing, ast building and pretty printing support for C++ throw expressions. Patch by Mike Stump! llvm-svn: 47582
2008-02-26 08:51:44 +08:00
/// ParseThrowExpression - This handles the C++ throw expression.
///
/// throw-expression: [C++ 15]
/// 'throw' assignment-expression[opt]
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Parser::ParseThrowExpression() {
add parsing, ast building and pretty printing support for C++ throw expressions. Patch by Mike Stump! llvm-svn: 47582
2008-02-26 08:51:44 +08:00
assert(Tok.is(tok::kw_throw) && "Not throw!");
SourceLocation ThrowLoc = ConsumeToken(); // Eat the throw token.
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
finish up throw parsing. llvm-svn: 49266
2008-04-06 14:02:23 +08:00
// If the current token isn't the start of an assignment-expression,
// then the expression is not present. This handles things like:
// "C ? throw : (void)42", which is crazy but legal.
switch (Tok.getKind()) { // FIXME: move this predicate somewhere common.
case tok::semi:
case tok::r_paren:
case tok::r_square:
case tok::r_brace:
case tok::colon:
case tok::comma:
Kill off ExprArg (now just Expr*) and StmtArg (now just Stmt*). llvm-svn: 111863
2010-08-24 07:25:46 +08:00
return Actions.ActOnCXXThrow(ThrowLoc, 0);
add parsing, ast building and pretty printing support for C++ throw expressions. Patch by Mike Stump! llvm-svn: 47582
2008-02-26 08:51:44 +08:00
finish up throw parsing. llvm-svn: 49266
2008-04-06 14:02:23 +08:00
default:
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Expr(ParseAssignmentExpression());
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
if (Expr.isInvalid()) return move(Expr);
Kill off ExprArg (now just Expr*) and StmtArg (now just Stmt*). llvm-svn: 111863
2010-08-24 07:25:46 +08:00
return Actions.ActOnCXXThrow(ThrowLoc, Expr.take());
finish up throw parsing. llvm-svn: 49266
2008-04-06 14:02:23 +08:00
}
add parsing, ast building and pretty printing support for C++ throw expressions. Patch by Mike Stump! llvm-svn: 47582
2008-02-26 08:51:44 +08:00
}
Add parsing support for C++ classes. Note that Parser::ParseCXXMemberSpecification is temporarily disabled until the Sema support is in place. Once ParseCXXMemberSpecification is enabled, the Parser/cxx-class.cpp test will pass. llvm-svn: 52694
2008-06-25 06:12:16 +08:00
/// ParseCXXThis - This handles the C++ 'this' pointer.
///
/// C++ 9.3.2: In the body of a non-static member function, the keyword this is
/// a non-lvalue expression whose value is the address of the object for which
/// the function is called.
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Parser::ParseCXXThis() {
Add parsing support for C++ classes. Note that Parser::ParseCXXMemberSpecification is temporarily disabled until the Sema support is in place. Once ParseCXXMemberSpecification is enabled, the Parser/cxx-class.cpp test will pass. llvm-svn: 52694
2008-06-25 06:12:16 +08:00
assert(Tok.is(tok::kw_this) && "Not 'this'!");
SourceLocation ThisLoc = ConsumeToken();
Convert a bunch of actions to smart pointers, and also bring PrintParserCallbacks a bit more in line with reality. llvm-svn: 67029
2009-03-16 01:47:39 +08:00
return Actions.ActOnCXXThis(ThisLoc);
Add parsing support for C++ classes. Note that Parser::ParseCXXMemberSpecification is temporarily disabled until the Sema support is in place. Once ParseCXXMemberSpecification is enabled, the Parser/cxx-class.cpp test will pass. llvm-svn: 52694
2008-06-25 06:12:16 +08:00
}
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
/// ParseCXXTypeConstructExpression - Parse construction of a specified type.
/// Can be interpreted either as function-style casting ("int(x)")
/// or class type construction ("ClassType(x,y,z)")
/// or creation of a value-initialized type ("int()").
///
/// postfix-expression: [C++ 5.2p1]
/// simple-type-specifier '(' expression-list[opt] ')' [C++ 5.2.3]
/// typename-specifier '(' expression-list[opt] ')' [TODO]
///
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
Parser::ParseCXXTypeConstructExpression(const DeclSpec &DS) {
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
Declarator DeclaratorInfo(DS, Declarator::TypeNameContext);
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ParsedType TypeRep = Actions.ActOnTypeName(getCurScope(), DeclaratorInfo).get();
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
assert(Tok.is(tok::l_paren) && "Expected '('!");
SourceLocation LParenLoc = ConsumeParen();
Use RAII objects to ensure proper destruction of expression and statement AST nodes in the parser in most cases, even on error. llvm-svn: 60057
2008-11-26 06:21:31 +08:00
ExprVector Exprs(Actions);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
CommaLocsTy CommaLocs;
if (Tok.isNot(tok::r_paren)) {
if (ParseExpressionList(Exprs, CommaLocs)) {
SkipUntil(tok::r_paren);
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError();
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
}
}
// Match the ')'.
SourceLocation RParenLoc = MatchRHSPunctuation(tok::r_paren, LParenLoc);
Make functional-style casts emit correct messages, and fix a crash-on-invalid. llvm-svn: 77451
2009-07-29 21:50:23 +08:00
// TypeRep could be null, if it references an invalid typedef.
if (!TypeRep)
return ExprError();
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
assert((Exprs.size() == 0 || Exprs.size()-1 == CommaLocs.size())&&
"Unexpected number of commas!");
Provide proper type-source location information for CXXTemporaryObjectExpr, CXXScalarValueInitExpr, and CXXUnresolvedConstructExpr, getting rid of a bunch of FIXMEs in the process. llvm-svn: 113319
2010-09-08 08:15:04 +08:00
return Actions.ActOnCXXTypeConstructExpr(TypeRep, LParenLoc, move_arg(Exprs),
Eliminate the comma locations from all of the Sema routines that deal with comma-separated lists. We never actually used the comma locations, nor did we store them in the AST, but we did manage to waste time during template instantiation to produce fake locations. llvm-svn: 113495
2010-09-10 00:33:13 +08:00
RParenLoc);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
}
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
/// ParseCXXCondition - if/switch/while condition expression.
Implement parser support for the 'condition' part of C++ selection-statements and iteration-statements (if/switch/while/for). Add new 'ActOnCXXConditionDeclarationExpr' action, called when the 'condition' is a declaration instead of an expression. llvm-svn: 56007
2008-09-10 04:38:47 +08:00
///
/// condition:
/// expression
/// type-specifier-seq declarator '=' assignment-expression
/// [GNU] type-specifier-seq declarator simple-asm-expr[opt] attributes[opt]
/// '=' assignment-expression
///
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
/// \param ExprResult if the condition was parsed as an expression, the
/// parsed expression.
///
/// \param DeclResult if the condition was parsed as a declaration, the
/// parsed declaration.
///
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
/// \param Loc The location of the start of the statement that requires this
/// condition, e.g., the "for" in a for loop.
///
/// \param ConvertToBoolean Whether the condition expression should be
/// converted to a boolean value.
///
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
/// \returns true if there was a parsing, false otherwise.
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
bool Parser::ParseCXXCondition(ExprResult &ExprOut,
Decl *&DeclOut,
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
SourceLocation Loc,
bool ConvertToBoolean) {
Improve code completion by introducing patterns for the various C and C++ grammatical constructs that show up in top-level (namespace-level) declarations, member declarations, template declarations, statements, expressions, conditions, etc. For example, we now provide a pattern for static_cast<type>(expr) when we can have an expression, or using namespace identifier; when we can have a using directive. Also, improves the results of code completion at the beginning of a top-level declaration. Previously, we would see value names (function names, global variables, etc.); now we see types, namespace names, etc., but no values. llvm-svn: 93134
2010-01-11 07:08:15 +08:00
if (Tok.is(tok::code_completion)) {
One who seeks knowledge learns something new every day. One who seeks the Tao unlearns something new every day. Less and less remains until you arrive at non-action. When you arrive at non-action, nothing will be left undone. llvm-svn: 112244
2010-08-27 07:41:50 +08:00
Actions.CodeCompleteOrdinaryName(getCurScope(), Sema::PCC_Condition);
Improve code completion in failure cases in two ways: 1) Suppress diagnostics as soon as we form the code-completion token, so we don't get any error/warning spew from the early end-of-file. 2) If we consume a code-completion token when we weren't expecting one, go into a code-completion recovery path that produces the best results it can based on the context that the parser is in. llvm-svn: 104585
2010-05-25 13:58:43 +08:00
ConsumeCodeCompletionToken();
Improve code completion by introducing patterns for the various C and C++ grammatical constructs that show up in top-level (namespace-level) declarations, member declarations, template declarations, statements, expressions, conditions, etc. For example, we now provide a pattern for static_cast<type>(expr) when we can have an expression, or using namespace identifier; when we can have a using directive. Also, improves the results of code completion at the beginning of a top-level declaration. Previously, we would see value names (function names, global variables, etc.); now we see types, namespace names, etc., but no values. llvm-svn: 93134
2010-01-11 07:08:15 +08:00
}
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
if (!isCXXConditionDeclaration()) {
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
// Parse the expression.
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprOut = ParseExpression(); // expression
DeclOut = 0;
if (ExprOut.isInvalid())
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
return true;
// If required, convert to a boolean value.
if (ConvertToBoolean)
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprOut
= Actions.ActOnBooleanCondition(getCurScope(), Loc, ExprOut.get());
return ExprOut.isInvalid();
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
}
Implement parser support for the 'condition' part of C++ selection-statements and iteration-statements (if/switch/while/for). Add new 'ActOnCXXConditionDeclarationExpr' action, called when the 'condition' is a declaration instead of an expression. llvm-svn: 56007
2008-09-10 04:38:47 +08:00
// type-specifier-seq
DeclSpec DS;
ParseSpecifierQualifierList(DS);
// declarator
Declarator DeclaratorInfo(DS, Declarator::ConditionContext);
ParseDeclarator(DeclaratorInfo);
// simple-asm-expr[opt]
if (Tok.is(tok::kw_asm)) {
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
SourceLocation Loc;
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult AsmLabel(ParseSimpleAsm(&Loc));
Consistently use smart pointers for stmt and expr nodes in parser local variables. llvm-svn: 60761
2008-12-09 21:15:23 +08:00
if (AsmLabel.isInvalid()) {
Implement parser support for the 'condition' part of C++ selection-statements and iteration-statements (if/switch/while/for). Add new 'ActOnCXXConditionDeclarationExpr' action, called when the 'condition' is a declaration instead of an expression. llvm-svn: 56007
2008-09-10 04:38:47 +08:00
SkipUntil(tok::semi);
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
return true;
Implement parser support for the 'condition' part of C++ selection-statements and iteration-statements (if/switch/while/for). Add new 'ActOnCXXConditionDeclarationExpr' action, called when the 'condition' is a declaration instead of an expression. llvm-svn: 56007
2008-09-10 04:38:47 +08:00
}
Modify the move emulation according to the excellent design of Howard Hinnant. Makes for much nicer syntax when smart pointers are used consistently. Also, start converting internal argument passing of Parser to smart pointers. llvm-svn: 60809
2008-12-10 08:02:53 +08:00
DeclaratorInfo.setAsmLabel(AsmLabel.release());
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
DeclaratorInfo.SetRangeEnd(Loc);
Implement parser support for the 'condition' part of C++ selection-statements and iteration-statements (if/switch/while/for). Add new 'ActOnCXXConditionDeclarationExpr' action, called when the 'condition' is a declaration instead of an expression. llvm-svn: 56007
2008-09-10 04:38:47 +08:00
}
// If attributes are present, parse them.
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
if (Tok.is(tok::kw___attribute)) {
SourceLocation Loc;
Added rudimentary C++0x attribute support. 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
2009-11-21 16:43:09 +08:00
AttributeList *AttrList = ParseGNUAttributes(&Loc);
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
DeclaratorInfo.AddAttributes(AttrList, Loc);
}
Implement parser support for the 'condition' part of C++ selection-statements and iteration-statements (if/switch/while/for). Add new 'ActOnCXXConditionDeclarationExpr' action, called when the 'condition' is a declaration instead of an expression. llvm-svn: 56007
2008-09-10 04:38:47 +08:00
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
// Type-check the declaration itself.
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
DeclResult Dcl = Actions.ActOnCXXConditionDeclaration(getCurScope(),
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
DeclaratorInfo);
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
DeclOut = Dcl.get();
ExprOut = ExprError();
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
Implement parser support for the 'condition' part of C++ selection-statements and iteration-statements (if/switch/while/for). Add new 'ActOnCXXConditionDeclarationExpr' action, called when the 'condition' is a declaration instead of an expression. llvm-svn: 56007
2008-09-10 04:38:47 +08:00
// '=' assignment-expression
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
if (Tok.is(tok::equal)) {
SourceLocation EqualLoc = ConsumeToken();
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult AssignExpr(ParseAssignmentExpression());
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
if (!AssignExpr.isInvalid())
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
Actions.AddInitializerToDecl(DeclOut, AssignExpr.take());
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
} else {
// FIXME: C++0x allows a braced-init-list
Diag(Tok, diag::err_expected_equal_after_declarator);
}
Rework our handling of temporary objects within the conditions of if/switch/while/do/for statements. Previously, we would end up either: (1) Forgetting to destroy temporaries created in the condition (!), (2) Destroying the temporaries created in the condition *before* converting the condition to a boolean value (or, in the case of a switch statement, to an integral or enumeral value), or (3) In a for statement, destroying the condition's temporaries at the end of the increment expression (!). We now destroy temporaries in conditions at the right times. This required some tweaking of the Parse/Sema interaction, since the parser was building full expressions too early in many places. Fixes PR7067. llvm-svn: 103187
2010-05-07 01:25:47 +08:00
// FIXME: Build a reference to this declaration? Convert it to bool?
// (This is currently handled by Sema).
Eliminate CXXConditionDeclExpr with extreme prejudice. All statements that involve conditions can now hold on to a separate condition declaration (a VarDecl), and will use a DeclRefExpr referring to that VarDecl for the condition expression. ForStmts now have such a VarDecl (I'd missed those in previous commits). Also, since this change reworks the Action interface for if/while/switch/for, use FullExprArg for the full expressions in those expressions, to ensure that we're emitting Note that we are (still) not generating the right cleanups for condition variables in for statements. That will be a follow-on commit. llvm-svn: 89817
2009-11-25 08:27:52 +08:00
return false;
Implement parser support for the 'condition' part of C++ selection-statements and iteration-statements (if/switch/while/for). Add new 'ActOnCXXConditionDeclarationExpr' action, called when the 'condition' is a declaration instead of an expression. llvm-svn: 56007
2008-09-10 04:38:47 +08:00
}
Implement parsing for message sends in Objective-C++. Message sends in Objective-C++ have a more complex grammar than in Objective-C (surprise!), because (1) The receiver of an instance message can be a qualified name such as ::I or identity<I>::type. (2) Expressions in C++ can start with a type. The receiver grammar isn't actually ambiguous; it just takes a bit of work to parse past the type before deciding whether we have a type or expression. We do this in two places within the grammar: once for message sends and once when we're determining whether a []'d clause in an initializer list is a message send or a C99 designated initializer. This implementation of Objective-C++ message sends contains one known extension beyond GCC's implementation, which is to permit a typename-specifier as the receiver type for a class message, e.g., [typename compute_receiver_type<T>::type method]; Note that the same effect can be achieved in GCC by way of a typedef, e.g., typedef typename computed_receiver_type<T>::type Computed; [Computed method]; so this is merely a convenience. Note also that message sends still cannot involve dependent types or values. llvm-svn: 102031
2010-04-22 06:36:40 +08:00
/// \brief Determine whether the current token starts a C++
/// simple-type-specifier.
bool Parser::isCXXSimpleTypeSpecifier() const {
switch (Tok.getKind()) {
case tok::annot_typename:
case tok::kw_short:
case tok::kw_long:
case tok::kw_signed:
case tok::kw_unsigned:
case tok::kw_void:
case tok::kw_char:
case tok::kw_int:
case tok::kw_float:
case tok::kw_double:
case tok::kw_wchar_t:
case tok::kw_char16_t:
case tok::kw_char32_t:
case tok::kw_bool:
// FIXME: C++0x decltype support.
// GNU typeof support.
case tok::kw_typeof:
return true;
default:
break;
}
return false;
}
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
/// ParseCXXSimpleTypeSpecifier - [C++ 7.1.5.2] Simple type specifiers.
/// This should only be called when the current token is known to be part of
/// simple-type-specifier.
///
/// simple-type-specifier:
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
/// '::'[opt] nested-name-specifier[opt] type-name
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
/// '::'[opt] nested-name-specifier 'template' simple-template-id [TODO]
/// char
/// wchar_t
/// bool
/// short
/// int
/// long
/// signed
/// unsigned
/// float
/// double
/// void
/// [GNU] typeof-specifier
/// [C++0x] auto [TODO]
///
/// type-name:
/// class-name
/// enum-name
/// typedef-name
///
void Parser::ParseCXXSimpleTypeSpecifier(DeclSpec &DS) {
DS.SetRangeStart(Tok.getLocation());
const char *PrevSpec;
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
unsigned DiagID;
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
SourceLocation Loc = Tok.getLocation();
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
switch (Tok.getKind()) {
ParseCXXSimpleTypeSpecifier can only be called on things that are verified to be simple type specifiers, so there is no need for it to call TryAnnotateTypeOrScopeToken. Make MaybeParseCXXScopeSpecifier reject ::new and ::delete with a hard error now that it may never be transitively called in a context where these are legal. This allows me to start disentangling things more. llvm-svn: 61659
2009-01-05 08:13:00 +08:00
case tok::identifier: // foo::bar
case tok::coloncolon: // ::foo::bar
assert(0 && "Annotation token should already be formed!");
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
default:
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
assert(0 && "Not a simple-type-specifier token!");
abort();
ParseCXXSimpleTypeSpecifier can only be called on things that are verified to be simple type specifiers, so there is no need for it to call TryAnnotateTypeOrScopeToken. Make MaybeParseCXXScopeSpecifier reject ::new and ::delete with a hard error now that it may never be transitively called in a context where these are legal. This allows me to start disentangling things more. llvm-svn: 61659
2009-01-05 08:13:00 +08:00
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
// type-name
rename tok::annot_qualtypename -> tok::annot_typename, which is both shorter and more accurate. The type name might not be qualified. llvm-svn: 61788
2009-01-06 13:06:21 +08:00
case tok::annot_typename: {
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecType(DeclSpec::TST_typename, Loc, PrevSpec, DiagID,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
getTypeAnnotation(Tok));
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
// builtin types
case tok::kw_short:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecWidth(DeclSpec::TSW_short, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
case tok::kw_long:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecWidth(DeclSpec::TSW_long, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
case tok::kw_signed:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecSign(DeclSpec::TSS_signed, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
case tok::kw_unsigned:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecSign(DeclSpec::TSS_unsigned, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
case tok::kw_void:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecType(DeclSpec::TST_void, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
case tok::kw_char:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecType(DeclSpec::TST_char, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
case tok::kw_int:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecType(DeclSpec::TST_int, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
case tok::kw_float:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecType(DeclSpec::TST_float, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
case tok::kw_double:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecType(DeclSpec::TST_double, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
case tok::kw_wchar_t:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecType(DeclSpec::TST_wchar, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
Basic support for C++0x unicode types. Support for literals will follow in an incremental patch llvm-svn: 75622
2009-07-14 14:30:34 +08:00
case tok::kw_char16_t:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecType(DeclSpec::TST_char16, Loc, PrevSpec, DiagID);
Basic support for C++0x unicode types. Support for literals will follow in an incremental patch llvm-svn: 75622
2009-07-14 14:30:34 +08:00
break;
case tok::kw_char32_t:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecType(DeclSpec::TST_char32, Loc, PrevSpec, DiagID);
Basic support for C++0x unicode types. Support for literals will follow in an incremental patch llvm-svn: 75622
2009-07-14 14:30:34 +08:00
break;
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
case tok::kw_bool:
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
DS.SetTypeSpecType(DeclSpec::TST_bool, Loc, PrevSpec, DiagID);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
break;
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Implement parsing for message sends in Objective-C++. Message sends in Objective-C++ have a more complex grammar than in Objective-C (surprise!), because (1) The receiver of an instance message can be a qualified name such as ::I or identity<I>::type. (2) Expressions in C++ can start with a type. The receiver grammar isn't actually ambiguous; it just takes a bit of work to parse past the type before deciding whether we have a type or expression. We do this in two places within the grammar: once for message sends and once when we're determining whether a []'d clause in an initializer list is a message send or a C99 designated initializer. This implementation of Objective-C++ message sends contains one known extension beyond GCC's implementation, which is to permit a typename-specifier as the receiver type for a class message, e.g., [typename compute_receiver_type<T>::type method]; Note that the same effect can be achieved in GCC by way of a typedef, e.g., typedef typename computed_receiver_type<T>::type Computed; [Computed method]; so this is merely a convenience. Note also that message sends still cannot involve dependent types or values. llvm-svn: 102031
2010-04-22 06:36:40 +08:00
// FIXME: C++0x decltype support.
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
// GNU typeof support.
case tok::kw_typeof:
ParseTypeofSpecifier(DS);
Add code modification hints to various parsing-related diagnostics. Plus, reword a extension warnings to avoid talking about "ISO C" when the extension might also be available in C++ or C++0x. llvm-svn: 68257
2009-04-02 06:41:11 +08:00
DS.Finish(Diags, PP);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
return;
}
rename tok::annot_qualtypename -> tok::annot_typename, which is both shorter and more accurate. The type name might not be qualified. llvm-svn: 61788
2009-01-06 13:06:21 +08:00
if (Tok.is(tok::annot_typename))
Implement support for C++ nested-name-specifiers ('foo::bar::x') in the Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
2008-11-09 00:45:02 +08:00
DS.SetRangeEnd(Tok.getAnnotationEndLoc());
else
DS.SetRangeEnd(Tok.getLocation());
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
ConsumeToken();
Add code modification hints to various parsing-related diagnostics. Plus, reword a extension warnings to avoid talking about "ISO C" when the extension might also be available in C++ or C++0x. llvm-svn: 68257
2009-04-02 06:41:11 +08:00
DS.Finish(Diags, PP);
Add support for C++'s "type-specifier ( expression-list )" expression: -The Parser calls a new "ActOnCXXTypeConstructExpr" action. -Sema, depending on the type and expressions number: -If the type is a class, it will treat it as a class constructor. [TODO] -If there's only one expression (i.e. "int(0.5)" ), creates a new "CXXFunctionalCastExpr" Expr node -If there are no expressions (i.e "int()" ), creates a new "CXXZeroInitValueExpr" Expr node. llvm-svn: 55177
2008-08-22 23:38:55 +08:00
}
Parsing, ASTs, and semantic analysis for the declaration of overloaded operators in C++. Overloaded operators can be called directly via their operator-function-ids, e.g., "operator+(foo, bar)", but we don't yet implement the semantics of operator overloading to handle, e.g., "foo + bar". llvm-svn: 58817
2008-11-07 06:13:31 +08:00
Parsing, ASTs, and semantic analysis for the declaration of conversion functions in C++, e.g., struct X { operator bool() const; }; Note that these conversions don't actually do anything, since we don't yet have the ability to use them for implicit or explicit conversions. llvm-svn: 58860
2008-11-08 04:08:42 +08:00
/// ParseCXXTypeSpecifierSeq - Parse a C++ type-specifier-seq (C++
/// [dcl.name]), which is a non-empty sequence of type-specifiers,
/// e.g., "const short int". Note that the DeclSpec is *not* finished
/// by parsing the type-specifier-seq, because these sequences are
/// typically followed by some form of declarator. Returns true and
/// emits diagnostics if this is not a type-specifier-seq, false
/// otherwise.
///
/// type-specifier-seq: [C++ 8.1]
/// type-specifier type-specifier-seq[opt]
///
bool Parser::ParseCXXTypeSpecifierSeq(DeclSpec &DS) {
DS.SetRangeStart(Tok.getLocation());
const char *PrevSpec = 0;
Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect this elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. llvm-svn: 77990
2009-08-04 04:12:06 +08:00
unsigned DiagID;
bool isInvalid = 0;
Parsing, ASTs, and semantic analysis for the declaration of conversion functions in C++, e.g., struct X { operator bool() const; }; Note that these conversions don't actually do anything, since we don't yet have the ability to use them for implicit or explicit conversions. llvm-svn: 58860
2008-11-08 04:08:42 +08:00
// Parse one or more of the type specifiers.
In some contexts, type declarations cannot occur. Pass this information down to ParseClassSpecifier, to make its decision easier. Fixes PR6200. llvm-svn: 95255
2010-02-04 05:21:43 +08:00
if (!ParseOptionalTypeSpecifier(DS, isInvalid, PrevSpec, DiagID,
ParsedTemplateInfo(), /*SuppressDeclarations*/true)) {
Change a couple of the Parser::Diag methods to return DiagnosticInfo and let the clients push whatever they want into the DiagnosticInfo instead of hard coding a few forms. Also switch various clients to use Diag(Tok, ...) instead of Diag(Tok.getLocation(), ...) as the canonical form to simplify the code a bit. llvm-svn: 59509
2008-11-18 15:48:38 +08:00
Diag(Tok, diag::err_operator_missing_type_specifier);
Parsing, ASTs, and semantic analysis for the declaration of conversion functions in C++, e.g., struct X { operator bool() const; }; Note that these conversions don't actually do anything, since we don't yet have the ability to use them for implicit or explicit conversions. llvm-svn: 58860
2008-11-08 04:08:42 +08:00
return true;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
In some contexts, type declarations cannot occur. Pass this information down to ParseClassSpecifier, to make its decision easier. Fixes PR6200. llvm-svn: 95255
2010-02-04 05:21:43 +08:00
while (ParseOptionalTypeSpecifier(DS, isInvalid, PrevSpec, DiagID,
ParsedTemplateInfo(), /*SuppressDeclarations*/true))
{}
Parsing, ASTs, and semantic analysis for the declaration of conversion functions in C++, e.g., struct X { operator bool() const; }; Note that these conversions don't actually do anything, since we don't yet have the ability to use them for implicit or explicit conversions. llvm-svn: 58860
2008-11-08 04:08:42 +08:00
Make sure that we finish the DeclSpec when parsing a C++ type-specifier-seq. Fixes some conditional-jump-on-unitialized-value errors in valgrind. Also counts as attempt #2 at making the MSVC buildbot happy. llvm-svn: 97077
2010-02-25 07:13:13 +08:00
DS.Finish(Diags, PP);
Parsing, ASTs, and semantic analysis for the declaration of conversion functions in C++, e.g., struct X { operator bool() const; }; Note that these conversions don't actually do anything, since we don't yet have the ability to use them for implicit or explicit conversions. llvm-svn: 58860
2008-11-08 04:08:42 +08:00
return false;
}
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
/// \brief Finish parsing a C++ unqualified-id that is a template-id of
/// some form.
///
/// This routine is invoked when a '<' is encountered after an identifier or
/// operator-function-id is parsed by \c ParseUnqualifiedId() to determine
/// whether the unqualified-id is actually a template-id. This routine will
/// then parse the template arguments and form the appropriate template-id to
/// return to the caller.
///
/// \param SS the nested-name-specifier that precedes this template-id, if
/// we're actually parsing a qualified-id.
///
/// \param Name for constructor and destructor names, this is the actual
/// identifier that may be a template-name.
///
/// \param NameLoc the location of the class-name in a constructor or
/// destructor.
///
/// \param EnteringContext whether we're entering the scope of the
/// nested-name-specifier.
///
Tweak some comments about unqualified-id and id-expression parsing. No functionality change llvm-svn: 85942
2009-11-04 05:24:04 +08:00
/// \param ObjectType if this unqualified-id occurs within a member access
/// expression, the type of the base object whose member is being accessed.
///
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
/// \param Id as input, describes the template-name or operator-function-id
/// that precedes the '<'. If template arguments were parsed successfully,
/// will be updated with the template-id.
///
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
/// \param AssumeTemplateId When true, this routine will assume that the name
/// refers to a template without performing name lookup to verify.
///
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
/// \returns true if a parse error occurred, false otherwise.
bool Parser::ParseUnqualifiedIdTemplateId(CXXScopeSpec &SS,
IdentifierInfo *Name,
SourceLocation NameLoc,
bool EnteringContext,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ParsedType ObjectType,
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
UnqualifiedId &Id,
Support for 'template' as a disambiguator (PR7030) ParseOptionalCXXScopeSpecifier() only annotates the subset of template-ids which are not subject to lexical ambiguity. Add support for the more general case in ParseUnqualifiedId() to handle cases such as A::template B(). Also improve some diagnostic locations. Fixes PR7030, from Alp Toker! llvm-svn: 103081
2010-05-05 13:58:24 +08:00
bool AssumeTemplateId,
SourceLocation TemplateKWLoc) {
assert((AssumeTemplateId || Tok.is(tok::less)) &&
"Expected '<' to finish parsing a template-id");
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
TemplateTy Template;
TemplateNameKind TNK = TNK_Non_template;
switch (Id.getKind()) {
case UnqualifiedId::IK_Identifier:
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
case UnqualifiedId::IK_OperatorFunctionId:
Fix test and handle IK_LiteralOperatorId in a few more places. llvm-svn: 90030
2009-11-28 16:58:14 +08:00
case UnqualifiedId::IK_LiteralOperatorId:
Rework parsing of pseudo-destructor expressions and explicit destructor calls, e.g., p->T::~T We now detect when the member access that we've parsed, e.g., p-> or x. may be a pseudo-destructor expression, either because the type of p or x is a scalar or because it is dependent (and, therefore, may become a scalar at template instantiation time). We then parse the pseudo-destructor grammar specifically: ::[opt] nested-name-specifier[opt] type-name :: ∼ type-name and hand those results to a new action, ActOnPseudoDestructorExpr, which will cope with both dependent member accesses of destructors and with pseudo-destructor expressions. This commit affects the parsing of pseudo-destructors, only; the semantic actions still go through the semantic actions for member access expressions. That will change soon. llvm-svn: 97045
2010-02-25 02:44:31 +08:00
if (AssumeTemplateId) {
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
TNK = Actions.ActOnDependentTemplateName(getCurScope(), TemplateKWLoc, SS,
When we see a 'template' disambiguator that marks the next identifier (or operator-function-id) as a template, but the context is actually non-dependent or the current instantiation, allow us to use knowledge of what kind of template it is, e.g., type template vs. function template, for further syntactic disambiguation. This allows us to parse properly in the presence of stray "template" keywords, which is necessary in C++0x and it's good recovery in C++98/03. llvm-svn: 106167
2010-06-17 07:00:59 +08:00
Id, ObjectType, EnteringContext,
Template);
if (TNK == TNK_Non_template)
return true;
Improve parser recovery when we encounter a dependent template name that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
2010-05-22 07:18:07 +08:00
} else {
bool MemberOfUnknownSpecialization;
Template keyword should not be ignored building a QualifiedTemplateName. llvm-svn: 110441
2010-08-06 20:11:11 +08:00
TNK = Actions.isTemplateName(getCurScope(), SS,
TemplateKWLoc.isValid(), Id,
ObjectType, EnteringContext, Template,
Improve parser recovery when we encounter a dependent template name that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
2010-05-22 07:18:07 +08:00
MemberOfUnknownSpecialization);
if (TNK == TNK_Non_template && MemberOfUnknownSpecialization &&
ObjectType && IsTemplateArgumentList()) {
// We have something like t->getAs<T>(), where getAs is a
// member of an unknown specialization. However, this will only
// parse correctly as a template, so suggest the keyword 'template'
// before 'getAs' and treat this as a dependent template name.
std::string Name;
if (Id.getKind() == UnqualifiedId::IK_Identifier)
Name = Id.Identifier->getName();
else {
Name = "operator ";
if (Id.getKind() == UnqualifiedId::IK_OperatorFunctionId)
Name += getOperatorSpelling(Id.OperatorFunctionId.Operator);
else
Name += Id.Identifier->getName();
}
Diag(Id.StartLocation, diag::err_missing_dependent_template_keyword)
<< Name
<< FixItHint::CreateInsertion(Id.StartLocation, "template ");
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
TNK = Actions.ActOnDependentTemplateName(getCurScope(), TemplateKWLoc,
When we see a 'template' disambiguator that marks the next identifier (or operator-function-id) as a template, but the context is actually non-dependent or the current instantiation, allow us to use knowledge of what kind of template it is, e.g., type template vs. function template, for further syntactic disambiguation. This allows us to parse properly in the presence of stray "template" keywords, which is necessary in C++0x and it's good recovery in C++98/03. llvm-svn: 106167
2010-06-17 07:00:59 +08:00
SS, Id, ObjectType,
EnteringContext, Template);
if (TNK == TNK_Non_template)
Improve parser recovery when we encounter a dependent template name that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
2010-05-22 07:18:07 +08:00
return true;
}
}
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
break;
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
case UnqualifiedId::IK_ConstructorName: {
UnqualifiedId TemplateName;
Improve parser recovery when we encounter a dependent template name that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
2010-05-22 07:18:07 +08:00
bool MemberOfUnknownSpecialization;
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
TemplateName.setIdentifier(Name, NameLoc);
Template keyword should not be ignored building a QualifiedTemplateName. llvm-svn: 110441
2010-08-06 20:11:11 +08:00
TNK = Actions.isTemplateName(getCurScope(), SS, TemplateKWLoc.isValid(),
TemplateName, ObjectType,
Improve parser recovery when we encounter a dependent template name that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
2010-05-22 07:18:07 +08:00
EnteringContext, Template,
MemberOfUnknownSpecialization);
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
break;
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
}
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
case UnqualifiedId::IK_DestructorName: {
UnqualifiedId TemplateName;
Improve parser recovery when we encounter a dependent template name that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
2010-05-22 07:18:07 +08:00
bool MemberOfUnknownSpecialization;
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
TemplateName.setIdentifier(Name, NameLoc);
Replace the code that parses member access expressions after "." or "->" 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
2009-11-04 03:44:04 +08:00
if (ObjectType) {
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
TNK = Actions.ActOnDependentTemplateName(getCurScope(), TemplateKWLoc, SS,
When we see a 'template' disambiguator that marks the next identifier (or operator-function-id) as a template, but the context is actually non-dependent or the current instantiation, allow us to use knowledge of what kind of template it is, e.g., type template vs. function template, for further syntactic disambiguation. This allows us to parse properly in the presence of stray "template" keywords, which is necessary in C++0x and it's good recovery in C++98/03. llvm-svn: 106167
2010-06-17 07:00:59 +08:00
TemplateName, ObjectType,
EnteringContext, Template);
if (TNK == TNK_Non_template)
Replace the code that parses member access expressions after "." or "->" 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
2009-11-04 03:44:04 +08:00
return true;
} else {
Template keyword should not be ignored building a QualifiedTemplateName. llvm-svn: 110441
2010-08-06 20:11:11 +08:00
TNK = Actions.isTemplateName(getCurScope(), SS, TemplateKWLoc.isValid(),
TemplateName, ObjectType,
Improve parser recovery when we encounter a dependent template name that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
2010-05-22 07:18:07 +08:00
EnteringContext, Template,
MemberOfUnknownSpecialization);
Replace the code that parses member access expressions after "." or "->" 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
2009-11-04 03:44:04 +08:00
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
if (TNK == TNK_Non_template && !Id.DestructorName.get()) {
Improve parsing and instantiation of destructor names, so that we can now cope with the destruction of types named as dependent templates, e.g., y->template Y<T>::~Y() Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't follow the letter of the standard here because that would fail to parse template<typename T, typename U> X0<T, U>::~X0() { } properly. The problem is captured in core issue 339, which gives some (but not enough!) guidance. I expect to revisit this code when the resolution of 339 is clear, and/or we start capturing better source information for DeclarationNames. Fixes PR6152. llvm-svn: 96367
2010-02-17 03:09:40 +08:00
Diag(NameLoc, diag::err_destructor_template_id)
<< Name << SS.getRange();
Replace the code that parses member access expressions after "." or "->" 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
2009-11-04 03:44:04 +08:00
return true;
}
}
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
break;
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
}
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
default:
return false;
}
if (TNK == TNK_Non_template)
return false;
// Parse the enclosed template argument list.
SourceLocation LAngleLoc, RAngleLoc;
TemplateArgList TemplateArgs;
Support for 'template' as a disambiguator (PR7030) ParseOptionalCXXScopeSpecifier() only annotates the subset of template-ids which are not subject to lexical ambiguity. Add support for the more general case in ParseUnqualifiedId() to handle cases such as A::template B(). Also improve some diagnostic locations. Fixes PR7030, from Alp Toker! llvm-svn: 103081
2010-05-05 13:58:24 +08:00
if (Tok.is(tok::less) &&
ParseTemplateIdAfterTemplateName(Template, Id.StartLocation,
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
&SS, true, LAngleLoc,
TemplateArgs,
RAngleLoc))
return true;
if (Id.getKind() == UnqualifiedId::IK_Identifier ||
Fix test and handle IK_LiteralOperatorId in a few more places. llvm-svn: 90030
2009-11-28 16:58:14 +08:00
Id.getKind() == UnqualifiedId::IK_OperatorFunctionId ||
Id.getKind() == UnqualifiedId::IK_LiteralOperatorId) {
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
// Form a parsed representation of the template-id to be stored in the
// UnqualifiedId.
TemplateIdAnnotation *TemplateId
= TemplateIdAnnotation::Allocate(TemplateArgs.size());
if (Id.getKind() == UnqualifiedId::IK_Identifier) {
TemplateId->Name = Id.Identifier;
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
TemplateId->Operator = OO_None;
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
TemplateId->TemplateNameLoc = Id.StartLocation;
} else {
Parsing and semantic analysis for template-ids that name overloaded operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
2009-11-04 07:16:33 +08:00
TemplateId->Name = 0;
TemplateId->Operator = Id.OperatorFunctionId.Operator;
TemplateId->TemplateNameLoc = Id.StartLocation;
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
}
Push DeclGroupRefs and TemplateNames in an opaque but type-safe way through the parser. llvm-svn: 111800
2010-08-23 15:28:44 +08:00
TemplateId->Template = Template;
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
TemplateId->Kind = TNK;
TemplateId->LAngleLoc = LAngleLoc;
TemplateId->RAngleLoc = RAngleLoc;
Improve parsing of template arguments to lay the foundation for 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
2009-11-11 03:49:08 +08:00
ParsedTemplateArgument *Args = TemplateId->getTemplateArgs();
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
for (unsigned Arg = 0, ArgEnd = TemplateArgs.size();
Improve parsing of template arguments to lay the foundation for 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
2009-11-11 03:49:08 +08:00
Arg != ArgEnd; ++Arg)
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
Args[Arg] = TemplateArgs[Arg];
Id.setTemplateId(TemplateId);
return false;
}
// Bundle the template arguments together.
ASTTemplateArgsPtr TemplateArgsPtr(Actions, TemplateArgs.data(),
TemplateArgs.size());
// Constructor and destructor names.
One who seeks knowledge learns something new every day. One who seeks the Tao unlearns something new every day. Less and less remains until you arrive at non-action. When you arrive at non-action, nothing will be left undone. llvm-svn: 112244
2010-08-27 07:41:50 +08:00
TypeResult Type
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
= Actions.ActOnTemplateIdType(Template, NameLoc,
LAngleLoc, TemplateArgsPtr,
RAngleLoc);
if (Type.isInvalid())
return true;
if (Id.getKind() == UnqualifiedId::IK_ConstructorName)
Id.setConstructorName(Type.get(), NameLoc, RAngleLoc);
else
Id.setDestructorName(Id.StartLocation, Type.get(), RAngleLoc);
return false;
}
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
/// \brief Parse an operator-function-id or conversion-function-id as part
/// of a C++ unqualified-id.
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
///
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
/// This routine is responsible only for parsing the operator-function-id or
/// conversion-function-id; it does not handle template arguments in any way.
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
///
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
/// \code
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
/// operator-function-id: [C++ 13.5]
/// 'operator' operator
///
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
/// operator: one of
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
/// new delete new[] delete[]
/// + - * / % ^ & | ~
/// ! = < > += -= *= /= %=
/// ^= &= |= << >> >>= <<= == !=
/// <= >= && || ++ -- , ->* ->
/// () []
///
/// conversion-function-id: [C++ 12.3.2]
/// operator conversion-type-id
///
/// conversion-type-id:
/// type-specifier-seq conversion-declarator[opt]
///
/// conversion-declarator:
/// ptr-operator conversion-declarator[opt]
/// \endcode
///
/// \param The nested-name-specifier that preceded this unqualified-id. If
/// non-empty, then we are parsing the unqualified-id of a qualified-id.
///
/// \param EnteringContext whether we are entering the scope of the
/// nested-name-specifier.
///
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
/// \param ObjectType if this unqualified-id occurs within a member access
/// expression, the type of the base object whose member is being accessed.
///
/// \param Result on a successful parse, contains the parsed unqualified-id.
///
/// \returns true if parsing fails, false otherwise.
bool Parser::ParseUnqualifiedIdOperator(CXXScopeSpec &SS, bool EnteringContext,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ParsedType ObjectType,
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
UnqualifiedId &Result) {
assert(Tok.is(tok::kw_operator) && "Expected 'operator' keyword");
// Consume the 'operator' keyword.
SourceLocation KeywordLoc = ConsumeToken();
// Determine what kind of operator name we have.
unsigned SymbolIdx = 0;
SourceLocation SymbolLocations[3];
OverloadedOperatorKind Op = OO_None;
switch (Tok.getKind()) {
case tok::kw_new:
case tok::kw_delete: {
bool isNew = Tok.getKind() == tok::kw_new;
// Consume the 'new' or 'delete'.
SymbolLocations[SymbolIdx++] = ConsumeToken();
if (Tok.is(tok::l_square)) {
// Consume the '['.
SourceLocation LBracketLoc = ConsumeBracket();
// Consume the ']'.
SourceLocation RBracketLoc = MatchRHSPunctuation(tok::r_square,
LBracketLoc);
if (RBracketLoc.isInvalid())
return true;
SymbolLocations[SymbolIdx++] = LBracketLoc;
SymbolLocations[SymbolIdx++] = RBracketLoc;
Op = isNew? OO_Array_New : OO_Array_Delete;
} else {
Op = isNew? OO_New : OO_Delete;
}
break;
}
#define OVERLOADED_OPERATOR(Name,Spelling,Token,Unary,Binary,MemberOnly) \
case tok::Token: \
SymbolLocations[SymbolIdx++] = ConsumeToken(); \
Op = OO_##Name; \
break;
#define OVERLOADED_OPERATOR_MULTI(Name,Spelling,Unary,Binary,MemberOnly)
#include "clang/Basic/OperatorKinds.def"
case tok::l_paren: {
// Consume the '('.
SourceLocation LParenLoc = ConsumeParen();
// Consume the ')'.
SourceLocation RParenLoc = MatchRHSPunctuation(tok::r_paren,
LParenLoc);
if (RParenLoc.isInvalid())
return true;
SymbolLocations[SymbolIdx++] = LParenLoc;
SymbolLocations[SymbolIdx++] = RParenLoc;
Op = OO_Call;
break;
}
case tok::l_square: {
// Consume the '['.
SourceLocation LBracketLoc = ConsumeBracket();
// Consume the ']'.
SourceLocation RBracketLoc = MatchRHSPunctuation(tok::r_square,
LBracketLoc);
if (RBracketLoc.isInvalid())
return true;
SymbolLocations[SymbolIdx++] = LBracketLoc;
SymbolLocations[SymbolIdx++] = RBracketLoc;
Op = OO_Subscript;
break;
}
case tok::code_completion: {
// Code completion for the operator name.
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
Actions.CodeCompleteOperatorName(getCurScope());
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
// Consume the operator token.
Improve code completion in failure cases in two ways: 1) Suppress diagnostics as soon as we form the code-completion token, so we don't get any error/warning spew from the early end-of-file. 2) If we consume a code-completion token when we weren't expecting one, go into a code-completion recovery path that produces the best results it can based on the context that the parser is in. llvm-svn: 104585
2010-05-25 13:58:43 +08:00
ConsumeCodeCompletionToken();
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
// Don't try to parse any further.
return true;
}
default:
break;
}
if (Op != OO_None) {
// We have parsed an operator-function-id.
Result.setOperatorFunctionId(KeywordLoc, Op, SymbolLocations);
return false;
}
Add Parser support for C++0x literal operators ('operator "" i'). DeclarationName can't handle them yet, so right now Parser just errors out on them. llvm-svn: 90027
2009-11-28 12:44:28 +08:00
// Parse a literal-operator-id.
//
// literal-operator-id: [C++0x 13.5.8]
// operator "" identifier
if (getLang().CPlusPlus0x && Tok.is(tok::string_literal)) {
if (Tok.getLength() != 2)
Diag(Tok.getLocation(), diag::err_operator_string_not_empty);
ConsumeStringToken();
if (Tok.isNot(tok::identifier)) {
Diag(Tok.getLocation(), diag::err_expected_ident);
return true;
}
IdentifierInfo *II = Tok.getIdentifierInfo();
Result.setLiteralOperatorId(II, KeywordLoc, ConsumeToken());
Add DeclarationName support for C++0x operator literals. They should now work as function names outside of templates - they'll probably cause some damage there as they're largely untested. llvm-svn: 90064
2009-11-29 15:34:05 +08:00
return false;
Add Parser support for C++0x literal operators ('operator "" i'). DeclarationName can't handle them yet, so right now Parser just errors out on them. llvm-svn: 90027
2009-11-28 12:44:28 +08:00
}
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
// Parse a conversion-function-id.
//
// conversion-function-id: [C++ 12.3.2]
// operator conversion-type-id
//
// conversion-type-id:
// type-specifier-seq conversion-declarator[opt]
//
// conversion-declarator:
// ptr-operator conversion-declarator[opt]
// Parse the type-specifier-seq.
DeclSpec DS;
Implement C++ [basic.lookup.classref]p3, which states how the type 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
2009-11-21 06:03:38 +08:00
if (ParseCXXTypeSpecifierSeq(DS)) // FIXME: ObjectType?
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
return true;
// Parse the conversion-declarator, which is merely a sequence of
// ptr-operators.
Declarator D(DS, Declarator::TypeNameContext);
ParseDeclaratorInternal(D, /*DirectDeclParser=*/0);
// Finish up the type.
One who seeks knowledge learns something new every day. One who seeks the Tao unlearns something new every day. Less and less remains until you arrive at non-action. When you arrive at non-action, nothing will be left undone. llvm-svn: 112244
2010-08-27 07:41:50 +08:00
TypeResult Ty = Actions.ActOnTypeName(getCurScope(), D);
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
if (Ty.isInvalid())
return true;
// Note that this is a conversion-function-id.
Result.setConversionFunctionId(KeywordLoc, Ty.get(),
D.getSourceRange().getEnd());
return false;
}
/// \brief Parse a C++ unqualified-id (or a C identifier), which describes the
/// name of an entity.
///
/// \code
/// unqualified-id: [C++ expr.prim.general]
/// identifier
/// operator-function-id
/// conversion-function-id
/// [C++0x] literal-operator-id [TODO]
/// ~ class-name
/// template-id
///
/// \endcode
///
/// \param The nested-name-specifier that preceded this unqualified-id. If
/// non-empty, then we are parsing the unqualified-id of a qualified-id.
///
/// \param EnteringContext whether we are entering the scope of the
/// nested-name-specifier.
///
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
/// \param AllowDestructorName whether we allow parsing of a destructor name.
///
/// \param AllowConstructorName whether we allow parsing a constructor name.
///
Tweak some comments about unqualified-id and id-expression parsing. No functionality change llvm-svn: 85942
2009-11-04 05:24:04 +08:00
/// \param ObjectType if this unqualified-id occurs within a member access
/// expression, the type of the base object whose member is being accessed.
///
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
/// \param Result on a successful parse, contains the parsed unqualified-id.
///
/// \returns true if parsing fails, false otherwise.
bool Parser::ParseUnqualifiedId(CXXScopeSpec &SS, bool EnteringContext,
bool AllowDestructorName,
bool AllowConstructorName,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ParsedType ObjectType,
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
UnqualifiedId &Result) {
Support for 'template' as a disambiguator (PR7030) ParseOptionalCXXScopeSpecifier() only annotates the subset of template-ids which are not subject to lexical ambiguity. Add support for the more general case in ParseUnqualifiedId() to handle cases such as A::template B(). Also improve some diagnostic locations. Fixes PR7030, from Alp Toker! llvm-svn: 103081
2010-05-05 13:58:24 +08:00
// Handle 'A::template B'. This is for template-ids which have not
// already been annotated by ParseOptionalCXXScopeSpecifier().
bool TemplateSpecified = false;
SourceLocation TemplateKWLoc;
if (getLang().CPlusPlus && Tok.is(tok::kw_template) &&
(ObjectType || SS.isSet())) {
TemplateSpecified = true;
TemplateKWLoc = ConsumeToken();
}
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
// unqualified-id:
// identifier
// template-id (when it hasn't already been annotated)
if (Tok.is(tok::identifier)) {
// Consume the identifier.
IdentifierInfo *Id = Tok.getIdentifierInfo();
SourceLocation IdLoc = ConsumeToken();
Eliminate an embarrassing performance regression in C/ObjC, where we were performing name lookup for template names in C/ObjC and always finding nothing. Turn off such lookup unless we're in C++ mode, along with the check that determines whether the given identifier is a "current class name", and assert that we don't make this mistake again. llvm-svn: 93207
2010-01-12 07:29:10 +08:00
if (!getLang().CPlusPlus) {
// If we're not in C++, only identifiers matter. Record the
// identifier and return.
Result.setIdentifier(Id, IdLoc);
return false;
}
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
if (AllowConstructorName &&
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
Actions.isCurrentClassName(*Id, getCurScope(), &SS)) {
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
// We have parsed a constructor name.
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
Result.setConstructorName(Actions.getTypeName(*Id, IdLoc, getCurScope(),
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
&SS, false),
IdLoc, IdLoc);
} else {
// We have parsed an identifier.
Result.setIdentifier(Id, IdLoc);
}
// If the next token is a '<', we may have a template.
Support for 'template' as a disambiguator (PR7030) ParseOptionalCXXScopeSpecifier() only annotates the subset of template-ids which are not subject to lexical ambiguity. Add support for the more general case in ParseUnqualifiedId() to handle cases such as A::template B(). Also improve some diagnostic locations. Fixes PR7030, from Alp Toker! llvm-svn: 103081
2010-05-05 13:58:24 +08:00
if (TemplateSpecified || Tok.is(tok::less))
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
return ParseUnqualifiedIdTemplateId(SS, Id, IdLoc, EnteringContext,
Support for 'template' as a disambiguator (PR7030) ParseOptionalCXXScopeSpecifier() only annotates the subset of template-ids which are not subject to lexical ambiguity. Add support for the more general case in ParseUnqualifiedId() to handle cases such as A::template B(). Also improve some diagnostic locations. Fixes PR7030, from Alp Toker! llvm-svn: 103081
2010-05-05 13:58:24 +08:00
ObjectType, Result,
TemplateSpecified, TemplateKWLoc);
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
return false;
}
// unqualified-id:
// template-id (already parsed and annotated)
if (Tok.is(tok::annot_template_id)) {
Reimplement constructor declarator parsing to cope with template-ids that name constructors, the endless joys of out-of-line constructor definitions, and various other corner cases that the previous hack never imagined. Fixes PR5688 and tightens up semantic analysis for constructor names. Additionally, fixed a problem where we wouldn't properly enter the declarator scope of a parenthesized declarator. We were entering the scope, then leaving it when we saw the ")"; now, we re-enter the declarator scope before parsing the parameter list. Note that we are forced to perform some tentative parsing within a class (call it C) to tell the difference between C(int); // constructor and C (f)(int); // member function which is rather unfortunate. And, although it isn't necessary for correctness, we use the same tentative-parsing mechanism for out-of-line constructors to improve diagnostics in icky cases like: C::C C::f(int); // error: C::C refers to the constructor name, but // we complain nicely and recover by treating it as // a type. llvm-svn: 93322
2010-01-14 01:31:36 +08:00
TemplateIdAnnotation *TemplateId
= static_cast<TemplateIdAnnotation*>(Tok.getAnnotationValue());
// If the template-name names the current class, then this is a constructor
if (AllowConstructorName && TemplateId->Name &&
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
Actions.isCurrentClassName(*TemplateId->Name, getCurScope(), &SS)) {
Reimplement constructor declarator parsing to cope with template-ids that name constructors, the endless joys of out-of-line constructor definitions, and various other corner cases that the previous hack never imagined. Fixes PR5688 and tightens up semantic analysis for constructor names. Additionally, fixed a problem where we wouldn't properly enter the declarator scope of a parenthesized declarator. We were entering the scope, then leaving it when we saw the ")"; now, we re-enter the declarator scope before parsing the parameter list. Note that we are forced to perform some tentative parsing within a class (call it C) to tell the difference between C(int); // constructor and C (f)(int); // member function which is rather unfortunate. And, although it isn't necessary for correctness, we use the same tentative-parsing mechanism for out-of-line constructors to improve diagnostics in icky cases like: C::C C::f(int); // error: C::C refers to the constructor name, but // we complain nicely and recover by treating it as // a type. llvm-svn: 93322
2010-01-14 01:31:36 +08:00
if (SS.isSet()) {
// C++ [class.qual]p2 specifies that a qualified template-name
// is taken as the constructor name where a constructor can be
// declared. Thus, the template arguments are extraneous, so
// complain about them and remove them entirely.
Diag(TemplateId->TemplateNameLoc,
diag::err_out_of_line_constructor_template_id)
<< TemplateId->Name
Reinstate my CodeModificationHint -> FixItHint renaming patch, without the C-only "optimization". llvm-svn: 100022
2010-04-01 01:46:05 +08:00
<< FixItHint::CreateRemoval(
Reimplement constructor declarator parsing to cope with template-ids that name constructors, the endless joys of out-of-line constructor definitions, and various other corner cases that the previous hack never imagined. Fixes PR5688 and tightens up semantic analysis for constructor names. Additionally, fixed a problem where we wouldn't properly enter the declarator scope of a parenthesized declarator. We were entering the scope, then leaving it when we saw the ")"; now, we re-enter the declarator scope before parsing the parameter list. Note that we are forced to perform some tentative parsing within a class (call it C) to tell the difference between C(int); // constructor and C (f)(int); // member function which is rather unfortunate. And, although it isn't necessary for correctness, we use the same tentative-parsing mechanism for out-of-line constructors to improve diagnostics in icky cases like: C::C C::f(int); // error: C::C refers to the constructor name, but // we complain nicely and recover by treating it as // a type. llvm-svn: 93322
2010-01-14 01:31:36 +08:00
SourceRange(TemplateId->LAngleLoc, TemplateId->RAngleLoc));
Result.setConstructorName(Actions.getTypeName(*TemplateId->Name,
TemplateId->TemplateNameLoc,
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
getCurScope(),
Reimplement constructor declarator parsing to cope with template-ids that name constructors, the endless joys of out-of-line constructor definitions, and various other corner cases that the previous hack never imagined. Fixes PR5688 and tightens up semantic analysis for constructor names. Additionally, fixed a problem where we wouldn't properly enter the declarator scope of a parenthesized declarator. We were entering the scope, then leaving it when we saw the ")"; now, we re-enter the declarator scope before parsing the parameter list. Note that we are forced to perform some tentative parsing within a class (call it C) to tell the difference between C(int); // constructor and C (f)(int); // member function which is rather unfortunate. And, although it isn't necessary for correctness, we use the same tentative-parsing mechanism for out-of-line constructors to improve diagnostics in icky cases like: C::C C::f(int); // error: C::C refers to the constructor name, but // we complain nicely and recover by treating it as // a type. llvm-svn: 93322
2010-01-14 01:31:36 +08:00
&SS, false),
TemplateId->TemplateNameLoc,
TemplateId->RAngleLoc);
TemplateId->Destroy();
ConsumeToken();
return false;
}
Result.setConstructorTemplateId(TemplateId);
ConsumeToken();
return false;
}
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
// We have already parsed a template-id; consume the annotation token as
// our unqualified-id.
Reimplement constructor declarator parsing to cope with template-ids that name constructors, the endless joys of out-of-line constructor definitions, and various other corner cases that the previous hack never imagined. Fixes PR5688 and tightens up semantic analysis for constructor names. Additionally, fixed a problem where we wouldn't properly enter the declarator scope of a parenthesized declarator. We were entering the scope, then leaving it when we saw the ")"; now, we re-enter the declarator scope before parsing the parameter list. Note that we are forced to perform some tentative parsing within a class (call it C) to tell the difference between C(int); // constructor and C (f)(int); // member function which is rather unfortunate. And, although it isn't necessary for correctness, we use the same tentative-parsing mechanism for out-of-line constructors to improve diagnostics in icky cases like: C::C C::f(int); // error: C::C refers to the constructor name, but // we complain nicely and recover by treating it as // a type. llvm-svn: 93322
2010-01-14 01:31:36 +08:00
Result.setTemplateId(TemplateId);
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
ConsumeToken();
return false;
}
// unqualified-id:
// operator-function-id
// conversion-function-id
if (Tok.is(tok::kw_operator)) {
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
if (ParseUnqualifiedIdOperator(SS, EnteringContext, ObjectType, Result))
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
return true;
Fix test and handle IK_LiteralOperatorId in a few more places. llvm-svn: 90030
2009-11-28 16:58:14 +08:00
// If we have an operator-function-id or a literal-operator-id and the next
// token is a '<', we may have a
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
//
// template-id:
// operator-function-id < template-argument-list[opt] >
Fix test and handle IK_LiteralOperatorId in a few more places. llvm-svn: 90030
2009-11-28 16:58:14 +08:00
if ((Result.getKind() == UnqualifiedId::IK_OperatorFunctionId ||
Result.getKind() == UnqualifiedId::IK_LiteralOperatorId) &&
Support for 'template' as a disambiguator (PR7030) ParseOptionalCXXScopeSpecifier() only annotates the subset of template-ids which are not subject to lexical ambiguity. Add support for the more general case in ParseUnqualifiedId() to handle cases such as A::template B(). Also improve some diagnostic locations. Fixes PR7030, from Alp Toker! llvm-svn: 103081
2010-05-05 13:58:24 +08:00
(TemplateSpecified || Tok.is(tok::less)))
Implement support for parsing dependent template-ids that refer to overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
2009-11-04 08:56:37 +08:00
return ParseUnqualifiedIdTemplateId(SS, 0, SourceLocation(),
EnteringContext, ObjectType,
Support for 'template' as a disambiguator (PR7030) ParseOptionalCXXScopeSpecifier() only annotates the subset of template-ids which are not subject to lexical ambiguity. Add support for the more general case in ParseUnqualifiedId() to handle cases such as A::template B(). Also improve some diagnostic locations. Fixes PR7030, from Alp Toker! llvm-svn: 103081
2010-05-05 13:58:24 +08:00
Result,
TemplateSpecified, TemplateKWLoc);
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
return false;
}
Eliminate an embarrassing performance regression in C/ObjC, where we were performing name lookup for template names in C/ObjC and always finding nothing. Turn off such lookup unless we're in C++ mode, along with the check that determines whether the given identifier is a "current class name", and assert that we don't make this mistake again. llvm-svn: 93207
2010-01-12 07:29:10 +08:00
if (getLang().CPlusPlus &&
(AllowDestructorName || SS.isSet()) && Tok.is(tok::tilde)) {
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
// C++ [expr.unary.op]p10:
// There is an ambiguity in the unary-expression ~X(), where X is a
// class-name. The ambiguity is resolved in favor of treating ~ as a
// unary complement rather than treating ~X as referring to a destructor.
// Parse the '~'.
SourceLocation TildeLoc = ConsumeToken();
// Parse the class-name.
if (Tok.isNot(tok::identifier)) {
Improve parsing and instantiation of destructor names, so that we can now cope with the destruction of types named as dependent templates, e.g., y->template Y<T>::~Y() Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't follow the letter of the standard here because that would fail to parse template<typename T, typename U> X0<T, U>::~X0() { } properly. The problem is captured in core issue 339, which gives some (but not enough!) guidance. I expect to revisit this code when the resolution of 339 is clear, and/or we start capturing better source information for DeclarationNames. Fixes PR6152. llvm-svn: 96367
2010-02-17 03:09:40 +08:00
Diag(Tok, diag::err_destructor_tilde_identifier);
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
return true;
}
// Parse the class-name (or template-name in a simple-template-id).
IdentifierInfo *ClassName = Tok.getIdentifierInfo();
SourceLocation ClassNameLoc = ConsumeToken();
Support for 'template' as a disambiguator (PR7030) ParseOptionalCXXScopeSpecifier() only annotates the subset of template-ids which are not subject to lexical ambiguity. Add support for the more general case in ParseUnqualifiedId() to handle cases such as A::template B(). Also improve some diagnostic locations. Fixes PR7030, from Alp Toker! llvm-svn: 103081
2010-05-05 13:58:24 +08:00
if (TemplateSpecified || Tok.is(tok::less)) {
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
Result.setDestructorName(TildeLoc, ParsedType(), ClassNameLoc);
Replace the code that parses member access expressions after "." or "->" 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
2009-11-04 03:44:04 +08:00
return ParseUnqualifiedIdTemplateId(SS, ClassName, ClassNameLoc,
Support for 'template' as a disambiguator (PR7030) ParseOptionalCXXScopeSpecifier() only annotates the subset of template-ids which are not subject to lexical ambiguity. Add support for the more general case in ParseUnqualifiedId() to handle cases such as A::template B(). Also improve some diagnostic locations. Fixes PR7030, from Alp Toker! llvm-svn: 103081
2010-05-05 13:58:24 +08:00
EnteringContext, ObjectType, Result,
TemplateSpecified, TemplateKWLoc);
Replace the code that parses member access expressions after "." or "->" 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
2009-11-04 03:44:04 +08:00
}
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
// Note that this is a destructor name.
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ParsedType Ty = Actions.getDestructorName(TildeLoc, *ClassName,
ClassNameLoc, getCurScope(),
SS, ObjectType,
EnteringContext);
Improve parsing and instantiation of destructor names, so that we can now cope with the destruction of types named as dependent templates, e.g., y->template Y<T>::~Y() Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't follow the letter of the standard here because that would fail to parse template<typename T, typename U> X0<T, U>::~X0() { } properly. The problem is captured in core issue 339, which gives some (but not enough!) guidance. I expect to revisit this code when the resolution of 339 is clear, and/or we start capturing better source information for DeclarationNames. Fixes PR6152. llvm-svn: 96367
2010-02-17 03:09:40 +08:00
if (!Ty)
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
return true;
Improve parsing and instantiation of destructor names, so that we can now cope with the destruction of types named as dependent templates, e.g., y->template Y<T>::~Y() Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't follow the letter of the standard here because that would fail to parse template<typename T, typename U> X0<T, U>::~X0() { } properly. The problem is captured in core issue 339, which gives some (but not enough!) guidance. I expect to revisit this code when the resolution of 339 is clear, and/or we start capturing better source information for DeclarationNames. Fixes PR6152. llvm-svn: 96367
2010-02-17 03:09:40 +08:00
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
Result.setDestructorName(TildeLoc, Ty, ClassNameLoc);
return false;
}
Replace the code that parses member access expressions after "." or "->" 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
2009-11-04 03:44:04 +08:00
Diag(Tok, diag::err_expected_unqualified_id)
<< getLang().CPlusPlus;
Introduce a new class, UnqualifiedId, that provides a parsed 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
2009-11-03 09:35:08 +08:00
return true;
}
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
/// ParseCXXNewExpression - Parse a C++ new-expression. New is used to allocate
/// memory in a typesafe manner and call constructors.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
///
eliminate lookahead when parsing ::new / ::delete. llvm-svn: 61638
2009-01-05 05:25:24 +08:00
/// This method is called to parse the new expression after the optional :: has
/// been already parsed. If the :: was present, "UseGlobal" is true and "Start"
/// is its location. Otherwise, "Start" is the location of the 'new' token.
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
///
/// new-expression:
/// '::'[opt] 'new' new-placement[opt] new-type-id
/// new-initializer[opt]
/// '::'[opt] 'new' new-placement[opt] '(' type-id ')'
/// new-initializer[opt]
///
/// new-placement:
/// '(' expression-list ')'
///
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
/// new-type-id:
/// type-specifier-seq new-declarator[opt]
///
/// new-declarator:
/// ptr-operator new-declarator[opt]
/// direct-new-declarator
///
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
/// new-initializer:
/// '(' expression-list[opt] ')'
/// [C++0x] braced-init-list [TODO]
///
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult
eliminate lookahead when parsing ::new / ::delete. llvm-svn: 61638
2009-01-05 05:25:24 +08:00
Parser::ParseCXXNewExpression(bool UseGlobal, SourceLocation Start) {
assert(Tok.is(tok::kw_new) && "expected 'new' token");
ConsumeToken(); // Consume 'new'
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
// A '(' now can be a new-placement or the '(' wrapping the type-id in the
// second form of new-expression. It can't be a new-type-id.
Use RAII objects to ensure proper destruction of expression and statement AST nodes in the parser in most cases, even on error. llvm-svn: 60057
2008-11-26 06:21:31 +08:00
ExprVector PlacementArgs(Actions);
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
SourceLocation PlacementLParen, PlacementRParen;
Downgrade the "when type is in parentheses, array cannot have dynamic size" error for code like new (int [size]) to a warning, add a Fix-It to remove the parentheses, and make this diagnostic work properly when it occurs in a template instantiation. <rdar://problem/8018245>. llvm-svn: 108242
2010-07-13 23:54:32 +08:00
SourceRange TypeIdParens;
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
DeclSpec DS;
Declarator DeclaratorInfo(DS, Declarator::TypeNameContext);
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
if (Tok.is(tok::l_paren)) {
// If it turns out to be a placement, we change the type location.
PlacementLParen = ConsumeParen();
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
if (ParseExpressionListOrTypeId(PlacementArgs, DeclaratorInfo)) {
SkipUntil(tok::semi, /*StopAtSemi=*/true, /*DontConsume=*/true);
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError();
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
}
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
PlacementRParen = MatchRHSPunctuation(tok::r_paren, PlacementLParen);
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
if (PlacementRParen.isInvalid()) {
SkipUntil(tok::semi, /*StopAtSemi=*/true, /*DontConsume=*/true);
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError();
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
}
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
if (PlacementArgs.empty()) {
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
// Reset the placement locations. There was no placement.
Downgrade the "when type is in parentheses, array cannot have dynamic size" error for code like new (int [size]) to a warning, add a Fix-It to remove the parentheses, and make this diagnostic work properly when it occurs in a template instantiation. <rdar://problem/8018245>. llvm-svn: 108242
2010-07-13 23:54:32 +08:00
TypeIdParens = SourceRange(PlacementLParen, PlacementRParen);
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
PlacementLParen = PlacementRParen = SourceLocation();
} else {
// We still need the type.
if (Tok.is(tok::l_paren)) {
Downgrade the "when type is in parentheses, array cannot have dynamic size" error for code like new (int [size]) to a warning, add a Fix-It to remove the parentheses, and make this diagnostic work properly when it occurs in a template instantiation. <rdar://problem/8018245>. llvm-svn: 108242
2010-07-13 23:54:32 +08:00
TypeIdParens.setBegin(ConsumeParen());
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
ParseSpecifierQualifierList(DS);
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
DeclaratorInfo.SetSourceRange(DS.getSourceRange());
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
ParseDeclarator(DeclaratorInfo);
Downgrade the "when type is in parentheses, array cannot have dynamic size" error for code like new (int [size]) to a warning, add a Fix-It to remove the parentheses, and make this diagnostic work properly when it occurs in a template instantiation. <rdar://problem/8018245>. llvm-svn: 108242
2010-07-13 23:54:32 +08:00
TypeIdParens.setEnd(MatchRHSPunctuation(tok::r_paren,
TypeIdParens.getBegin()));
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
} else {
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
if (ParseCXXTypeSpecifierSeq(DS))
DeclaratorInfo.setInvalidType(true);
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
else {
DeclaratorInfo.SetSourceRange(DS.getSourceRange());
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
ParseDeclaratorInternal(DeclaratorInfo,
&Parser::ParseDirectNewDeclarator);
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
}
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
}
}
} else {
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
// A new-type-id is a simplified type-id, where essentially the
// direct-declarator is replaced by a direct-new-declarator.
if (ParseCXXTypeSpecifierSeq(DS))
DeclaratorInfo.setInvalidType(true);
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
else {
DeclaratorInfo.SetSourceRange(DS.getSourceRange());
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
ParseDeclaratorInternal(DeclaratorInfo,
&Parser::ParseDirectNewDeclarator);
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
}
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
}
This is a pretty big cleanup for how invalid decl/type are handle. This gets rid of a bunch of random InvalidDecl bools in sema, changing us to use the following approach: 1. When analyzing a declspec or declarator, if an error is found, we set a bit in Declarator saying that it is invalid. 2. Once the Decl is created by sema, we immediately set the isInvalid bit on it from what is in the declarator. From this point on, sema consistently looks at and sets the bit on the decl. This gives a very clear separation of concerns and simplifies a bunch of code. In addition to this, this patch makes these changes: 1. it renames DeclSpec::getInvalidType() -> isInvalidType(). 2. various "merge" functions no longer return bools: they just set the invalid bit on the dest decl if invalid. 3. The ActOnTypedefDeclarator/ActOnFunctionDeclarator/ActOnVariableDeclarator methods now set invalid on the decl returned instead of returning an invalid bit byref. 4. In SemaType, refering to a typedef that was invalid now propagates the bit into the resultant type. Stuff declared with the invalid typedef will now be marked invalid. 5. Various methods like CheckVariableDeclaration now return void and set the invalid bit on the decl they check. There are a few minor changes to tests with this, but the only major bad result is test/SemaCXX/constructor-recovery.cpp. I'll take a look at this next. llvm-svn: 70020
2009-04-25 16:06:05 +08:00
if (DeclaratorInfo.isInvalidType()) {
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
SkipUntil(tok::semi, /*StopAtSemi=*/true, /*DontConsume=*/true);
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError();
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
}
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
Use RAII objects to ensure proper destruction of expression and statement AST nodes in the parser in most cases, even on error. llvm-svn: 60057
2008-11-26 06:21:31 +08:00
ExprVector ConstructorArgs(Actions);
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
SourceLocation ConstructorLParen, ConstructorRParen;
if (Tok.is(tok::l_paren)) {
ConstructorLParen = ConsumeParen();
if (Tok.isNot(tok::r_paren)) {
CommaLocsTy CommaLocs;
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
if (ParseExpressionList(ConstructorArgs, CommaLocs)) {
SkipUntil(tok::semi, /*StopAtSemi=*/true, /*DontConsume=*/true);
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError();
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
}
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
}
ConstructorRParen = MatchRHSPunctuation(tok::r_paren, ConstructorLParen);
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
if (ConstructorRParen.isInvalid()) {
SkipUntil(tok::semi, /*StopAtSemi=*/true, /*DontConsume=*/true);
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError();
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
}
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
}
Convert a bunch of actions to smart pointers, and also bring PrintParserCallbacks a bit more in line with reality. llvm-svn: 67029
2009-03-16 01:47:39 +08:00
return Actions.ActOnCXXNew(Start, UseGlobal, PlacementLParen,
move_arg(PlacementArgs), PlacementRParen,
Downgrade the "when type is in parentheses, array cannot have dynamic size" error for code like new (int [size]) to a warning, add a Fix-It to remove the parentheses, and make this diagnostic work properly when it occurs in a template instantiation. <rdar://problem/8018245>. llvm-svn: 108242
2010-07-13 23:54:32 +08:00
TypeIdParens, DeclaratorInfo, ConstructorLParen,
Convert a bunch of actions to smart pointers, and also bring PrintParserCallbacks a bit more in line with reality. llvm-svn: 67029
2009-03-16 01:47:39 +08:00
move_arg(ConstructorArgs), ConstructorRParen);
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
}
/// ParseDirectNewDeclarator - Parses a direct-new-declarator. Intended to be
/// passed to ParseDeclaratorInternal.
///
/// direct-new-declarator:
/// '[' expression ']'
/// direct-new-declarator '[' constant-expression ']'
///
eliminate lookahead when parsing ::new / ::delete. llvm-svn: 61638
2009-01-05 05:25:24 +08:00
void Parser::ParseDirectNewDeclarator(Declarator &D) {
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
// Parse the array dimensions.
bool first = true;
while (Tok.is(tok::l_square)) {
SourceLocation LLoc = ConsumeBracket();
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Size(first ? ParseExpression()
Convert selected expression parsers to use smart pointers. llvm-svn: 60900
2008-12-12 05:36:32 +08:00
: ParseConstantExpression());
Consistently use smart pointers for stmt and expr nodes in parser local variables. llvm-svn: 60761
2008-12-09 21:15:23 +08:00
if (Size.isInvalid()) {
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
// Recover
SkipUntil(tok::r_square);
return;
}
first = false;
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
SourceLocation RLoc = MatchRHSPunctuation(tok::r_square, LLoc);
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
D.AddTypeInfo(DeclaratorChunk::getArray(0, /*static=*/false, /*star=*/false,
Keep track of the Expr used to describe the size of an array type, from Enea Zaffanella! llvm-svn: 74831
2009-07-06 23:59:29 +08:00
Size.release(), LLoc, RLoc),
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
RLoc);
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
if (RLoc.isInvalid())
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
return;
}
}
/// ParseExpressionListOrTypeId - Parse either an expression-list or a type-id.
/// This ambiguity appears in the syntax of the C++ new operator.
///
/// new-expression:
/// '::'[opt] 'new' new-placement[opt] '(' type-id ')'
/// new-initializer[opt]
///
/// new-placement:
/// '(' expression-list ')'
///
Sundry incremental steps towards killing off Action. llvm-svn: 111795
2010-08-23 14:44:23 +08:00
bool Parser::ParseExpressionListOrTypeId(
llvm::SmallVectorImpl<Expr*> &PlacementArgs,
eliminate lookahead when parsing ::new / ::delete. llvm-svn: 61638
2009-01-05 05:25:24 +08:00
Declarator &D) {
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
// The '(' was already consumed.
if (isTypeIdInParens()) {
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
ParseSpecifierQualifierList(D.getMutableDeclSpec());
Implement Declarator::getSourceRange(). llvm-svn: 64151
2009-02-10 02:23:29 +08:00
D.SetSourceRange(D.getDeclSpec().getSourceRange());
Handle new by passing the Declaration to the Action, not a processed type. llvm-svn: 60413
2008-12-02 22:43:59 +08:00
ParseDeclarator(D);
This is a pretty big cleanup for how invalid decl/type are handle. This gets rid of a bunch of random InvalidDecl bools in sema, changing us to use the following approach: 1. When analyzing a declspec or declarator, if an error is found, we set a bit in Declarator saying that it is invalid. 2. Once the Decl is created by sema, we immediately set the isInvalid bit on it from what is in the declarator. From this point on, sema consistently looks at and sets the bit on the decl. This gives a very clear separation of concerns and simplifies a bunch of code. In addition to this, this patch makes these changes: 1. it renames DeclSpec::getInvalidType() -> isInvalidType(). 2. various "merge" functions no longer return bools: they just set the invalid bit on the dest decl if invalid. 3. The ActOnTypedefDeclarator/ActOnFunctionDeclarator/ActOnVariableDeclarator methods now set invalid on the decl returned instead of returning an invalid bit byref. 4. In SemaType, refering to a typedef that was invalid now propagates the bit into the resultant type. Stuff declared with the invalid typedef will now be marked invalid. 5. Various methods like CheckVariableDeclaration now return void and set the invalid bit on the decl they check. There are a few minor changes to tests with this, but the only major bad result is test/SemaCXX/constructor-recovery.cpp. I'll take a look at this next. llvm-svn: 70020
2009-04-25 16:06:05 +08:00
return D.isInvalidType();
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
}
// It's not a type, it has to be an expression list.
// Discard the comma locations - ActOnCXXNew has enough parameters.
CommaLocsTy CommaLocs;
return ParseExpressionList(PlacementArgs, CommaLocs);
}
/// ParseCXXDeleteExpression - Parse a C++ delete-expression. Delete is used
/// to free memory allocated by new.
///
eliminate lookahead when parsing ::new / ::delete. llvm-svn: 61638
2009-01-05 05:25:24 +08:00
/// This method is called to parse the 'delete' expression after the optional
/// '::' has been already parsed. If the '::' was present, "UseGlobal" is true
/// and "Start" is its location. Otherwise, "Start" is the location of the
/// 'delete' token.
///
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
/// delete-expression:
/// '::'[opt] 'delete' cast-expression
/// '::'[opt] 'delete' '[' ']' cast-expression
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult
eliminate lookahead when parsing ::new / ::delete. llvm-svn: 61638
2009-01-05 05:25:24 +08:00
Parser::ParseCXXDeleteExpression(bool UseGlobal, SourceLocation Start) {
assert(Tok.is(tok::kw_delete) && "Expected 'delete' keyword");
ConsumeToken(); // Consume 'delete'
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
// Array delete?
bool ArrayDelete = false;
if (Tok.is(tok::l_square)) {
ArrayDelete = true;
SourceLocation LHS = ConsumeBracket();
SourceLocation RHS = MatchRHSPunctuation(tok::r_square, LHS);
if (RHS.isInvalid())
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return ExprError();
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
}
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Operand(ParseCastExpression(false));
Consistently use smart pointers for stmt and expr nodes in parser local variables. llvm-svn: 60761
2008-12-09 21:15:23 +08:00
if (Operand.isInvalid())
Convert a big bunch of expression parsers to use smart pointers. llvm-svn: 60906
2008-12-12 06:51:44 +08:00
return move(Operand);
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
Kill off ExprArg (now just Expr*) and StmtArg (now just Stmt*). llvm-svn: 111863
2010-08-24 07:25:46 +08:00
return Actions.ActOnCXXDelete(Start, UseGlobal, ArrayDelete, Operand.take());
Implementation of new and delete parsing and sema. This version uses VLAs to represent arrays. I'll try an alternative way next, but I want this safe first. llvm-svn: 59835
2008-11-22 03:14:01 +08:00
}
PODness and Type Traits Make C++ classes track the POD property (C++ [class]p4) Track the existence of a copy assignment operator. Implicitly declare the copy assignment operator if none is provided. Implement most of the parsing job for the G++ type traits extension. Fully implement the low-hanging fruit of the type traits: __is_pod: Whether a type is a POD. __is_class: Whether a type is a (non-union) class. __is_union: Whether a type is a union. __is_enum: Whether a type is an enum. __is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1). llvm-svn: 61746
2009-01-06 04:52:13 +08:00
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
static UnaryTypeTrait UnaryTypeTraitFromTokKind(tok::TokenKind kind) {
PODness and Type Traits Make C++ classes track the POD property (C++ [class]p4) Track the existence of a copy assignment operator. Implicitly declare the copy assignment operator if none is provided. Implement most of the parsing job for the G++ type traits extension. Fully implement the low-hanging fruit of the type traits: __is_pod: Whether a type is a POD. __is_class: Whether a type is a (non-union) class. __is_union: Whether a type is a union. __is_enum: Whether a type is an enum. __is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1). llvm-svn: 61746
2009-01-06 04:52:13 +08:00
switch(kind) {
default: assert(false && "Not a known unary type trait.");
case tok::kw___has_nothrow_assign: return UTT_HasNothrowAssign;
case tok::kw___has_nothrow_copy: return UTT_HasNothrowCopy;
case tok::kw___has_nothrow_constructor: return UTT_HasNothrowConstructor;
case tok::kw___has_trivial_assign: return UTT_HasTrivialAssign;
case tok::kw___has_trivial_copy: return UTT_HasTrivialCopy;
case tok::kw___has_trivial_constructor: return UTT_HasTrivialConstructor;
case tok::kw___has_trivial_destructor: return UTT_HasTrivialDestructor;
case tok::kw___has_virtual_destructor: return UTT_HasVirtualDestructor;
case tok::kw___is_abstract: return UTT_IsAbstract;
case tok::kw___is_class: return UTT_IsClass;
case tok::kw___is_empty: return UTT_IsEmpty;
case tok::kw___is_enum: return UTT_IsEnum;
case tok::kw___is_pod: return UTT_IsPOD;
case tok::kw___is_polymorphic: return UTT_IsPolymorphic;
case tok::kw___is_union: return UTT_IsUnion;
Introduce the notion of literal types, as specified in C++0x. llvm-svn: 90361
2009-12-03 08:13:20 +08:00
case tok::kw___is_literal: return UTT_IsLiteral;
PODness and Type Traits Make C++ classes track the POD property (C++ [class]p4) Track the existence of a copy assignment operator. Implicitly declare the copy assignment operator if none is provided. Implement most of the parsing job for the G++ type traits extension. Fully implement the low-hanging fruit of the type traits: __is_pod: Whether a type is a POD. __is_class: Whether a type is a (non-union) class. __is_union: Whether a type is a union. __is_enum: Whether a type is an enum. __is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1). llvm-svn: 61746
2009-01-06 04:52:13 +08:00
}
}
/// ParseUnaryTypeTrait - Parse the built-in unary type-trait
/// pseudo-functions that allow implementation of the TR1/C++0x type traits
/// templates.
///
/// primary-expression:
/// [GNU] unary-type-trait '(' type-id ')'
///
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Parser::ParseUnaryTypeTrait() {
PODness and Type Traits Make C++ classes track the POD property (C++ [class]p4) Track the existence of a copy assignment operator. Implicitly declare the copy assignment operator if none is provided. Implement most of the parsing job for the G++ type traits extension. Fully implement the low-hanging fruit of the type traits: __is_pod: Whether a type is a POD. __is_class: Whether a type is a (non-union) class. __is_union: Whether a type is a union. __is_enum: Whether a type is an enum. __is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1). llvm-svn: 61746
2009-01-06 04:52:13 +08:00
UnaryTypeTrait UTT = UnaryTypeTraitFromTokKind(Tok.getKind());
SourceLocation Loc = ConsumeToken();
SourceLocation LParen = Tok.getLocation();
if (ExpectAndConsume(tok::l_paren, diag::err_expected_lparen))
return ExprError();
// FIXME: Error reporting absolutely sucks! If the this fails to parse a type
// there will be cryptic errors about mismatched parentheses and missing
// specifiers.
Update Parser::ParseTypeName to return a TypeResult, which also tells us whether there was an error in trying to parse a type-name (type-id in C++). This allows propagation of errors further in the compiler, suppressing more bogus error messages. llvm-svn: 64922
2009-02-19 01:45:20 +08:00
TypeResult Ty = ParseTypeName();
PODness and Type Traits Make C++ classes track the POD property (C++ [class]p4) Track the existence of a copy assignment operator. Implicitly declare the copy assignment operator if none is provided. Implement most of the parsing job for the G++ type traits extension. Fully implement the low-hanging fruit of the type traits: __is_pod: Whether a type is a POD. __is_class: Whether a type is a (non-union) class. __is_union: Whether a type is a union. __is_enum: Whether a type is an enum. __is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1). llvm-svn: 61746
2009-01-06 04:52:13 +08:00
SourceLocation RParen = MatchRHSPunctuation(tok::r_paren, LParen);
Update Parser::ParseTypeName to return a TypeResult, which also tells us whether there was an error in trying to parse a type-name (type-id in C++). This allows propagation of errors further in the compiler, suppressing more bogus error messages. llvm-svn: 64922
2009-02-19 01:45:20 +08:00
if (Ty.isInvalid())
return ExprError();
Add proper type-source information to UnaryTypeTraitExpr, including libclang visitation. llvm-svn: 113492
2010-09-10 00:14:44 +08:00
return Actions.ActOnUnaryTypeTrait(UTT, Loc, Ty.get(), RParen);
PODness and Type Traits Make C++ classes track the POD property (C++ [class]p4) Track the existence of a copy assignment operator. Implicitly declare the copy assignment operator if none is provided. Implement most of the parsing job for the G++ type traits extension. Fully implement the low-hanging fruit of the type traits: __is_pod: Whether a type is a POD. __is_class: Whether a type is a (non-union) class. __is_union: Whether a type is a union. __is_enum: Whether a type is an enum. __is_polymorphic: Whether a type is polymorphic (C++ [class.virtual]p1). llvm-svn: 61746
2009-01-06 04:52:13 +08:00
}
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
/// ParseCXXAmbiguousParenExpression - We have parsed the left paren of a
/// parenthesized ambiguous type-id. This uses tentative parsing to disambiguate
/// based on the context past the parens.
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
Parser::ParseCXXAmbiguousParenExpression(ParenParseOption &ExprType,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ParsedType &CastTy,
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
SourceLocation LParenLoc,
SourceLocation &RParenLoc) {
assert(getLang().CPlusPlus && "Should only be called for C++!");
assert(ExprType == CastExpr && "Compound literals are not ambiguous!");
assert(isTypeIdInParens() && "Not a type-id!");
OwningExprResult -> ExprResult. This patch brought to you by M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
2010-08-24 14:29:42 +08:00
ExprResult Result(true);
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
CastTy = ParsedType();
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
// We need to disambiguate a very ugly part of the C++ syntax:
//
// (T())x; - type-id
// (T())*x; - type-id
// (T())/x; - expression
// (T()); - expression
//
// The bad news is that we cannot use the specialized tentative parser, since
// it can only verify that the thing inside the parens can be parsed as
// type-id, it is not useful for determining the context past the parens.
//
// The good news is that the parser can disambiguate this part without
Some minor comments modifications. There are no unnecessary action calls period (courtesy of the annotation scheme) and too many 'this means'.. llvm-svn: 72263
2009-05-22 23:12:46 +08:00
// making any unnecessary Action calls.
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
//
// It uses a scheme similar to parsing inline methods. The parenthesized
// tokens are cached, the context that follows is determined (possibly by
// parsing a cast-expression), and then we re-introduce the cached tokens
// into the token stream and parse them appropriately.
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
ParenParseOption ParseAs;
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
CachedTokens Toks;
// Store the tokens of the parentheses. We will parse them after we determine
// the context that follows them.
Make Parser::ConsumeAndStoreUntil() more consistent with Parser::SkipUntil(). ConsumeAndStoreUntil would stop at tok::unknown when caching an inline method definition while SkipUntil would go past it while parsing the method. Fixes PR 6903. llvm-svn: 102214
2010-04-24 05:20:12 +08:00
if (!ConsumeAndStoreUntil(tok::r_paren, Toks)) {
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
// We didn't find the ')' we expected.
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
MatchRHSPunctuation(tok::r_paren, LParenLoc);
return ExprError();
}
if (Tok.is(tok::l_brace)) {
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
ParseAs = CompoundLiteral;
} else {
bool NotCastExpr;
PR4122: Tweak the ambiguity handling to handle (S())() correctly. I've left out handling for stuff like (S())++ for the moment. llvm-svn: 72394
2009-05-26 03:41:42 +08:00
// FIXME: Special-case ++ and --: "(S())++;" is not a cast-expression
if (Tok.is(tok::l_paren) && NextToken().is(tok::r_paren)) {
NotCastExpr = true;
} else {
// Try parsing the cast-expression that may follow.
// If it is not a cast-expression, NotCastExpr will be true and no token
// will be consumed.
Result = ParseCastExpression(false/*isUnaryExpression*/,
false/*isAddressofOperand*/,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
NotCastExpr,
ParsedType()/*TypeOfCast*/);
PR4122: Tweak the ambiguity handling to handle (S())() correctly. I've left out handling for stuff like (S())++ for the moment. llvm-svn: 72394
2009-05-26 03:41:42 +08:00
}
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
// If we parsed a cast-expression, it's really a type-id, otherwise it's
// an expression.
ParseAs = NotCastExpr ? SimpleExpr : CastExpr;
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
// The current token should go after the cached tokens.
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
Toks.push_back(Tok);
// Re-enter the stored parenthesized tokens into the token stream, so we may
// parse them now.
PP.EnterTokenStream(Toks.data(), Toks.size(),
true/*DisableMacroExpansion*/, false/*OwnsTokens*/);
// Drop the current token and bring the first cached one. It's the same token
// as when we entered this function.
ConsumeAnyToken();
if (ParseAs >= CompoundLiteral) {
TypeResult Ty = ParseTypeName();
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
// Match the ')'.
if (Tok.is(tok::r_paren))
RParenLoc = ConsumeParen();
else
MatchRHSPunctuation(tok::r_paren, LParenLoc);
if (ParseAs == CompoundLiteral) {
ExprType = CompoundLiteral;
return ParseCompoundLiteralExpression(Ty.get(), LParenLoc, RParenLoc);
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
// We parsed '(' type-id ')' and the thing after it wasn't a '{'.
assert(ParseAs == CastExpr);
if (Ty.isInvalid())
return ExprError();
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
CastTy = Ty.get();
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
// Result is what ParseCastExpression returned earlier.
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
if (!Result.isInvalid())
Move the "current scope" state from the Parser into Action. This allows Sema some limited access to the current scope, which we only use in one way: when Sema is performing some kind of declaration that is not directly driven by the parser (e.g., due to template instantiatio or lazy declaration of a member), we can find the Scope associated with a DeclContext, if that DeclContext is still in the process of being parsed. Use this to make the implicit declaration of special member functions in a C++ class more "scope-less", rather than using the NULL Scope hack. llvm-svn: 107491
2010-07-03 01:43:08 +08:00
Result = Actions.ActOnCastExpr(getCurScope(), LParenLoc, CastTy, RParenLoc,
Kill off ExprArg (now just Expr*) and StmtArg (now just Stmt*). llvm-svn: 111863
2010-08-24 07:25:46 +08:00
Result.take());
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
return move(Result);
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
// Not a compound literal, and not followed by a cast-expression.
assert(ParseAs == SimpleExpr);
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
ExprType = SimpleExpr;
The disambiguation process for ambiguous paren expressions is not "side effects free", e.g: (T(*)(int[x+y])); is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id, so unnecessary Action calls are made for an unused (and possibly leaked) "x+y". Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached, the context that follows is determined (possibly by parsing a cast-expression), and then we re-introduce the cached tokens into the token stream and parse them appropriately. llvm-svn: 72279
2009-05-23 05:09:47 +08:00
Result = ParseExpression();
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
if (!Result.isInvalid() && Tok.is(tok::r_paren))
Kill off ExprArg (now just Expr*) and StmtArg (now just Stmt*). llvm-svn: 111863
2010-08-24 07:25:46 +08:00
Result = Actions.ActOnParenExpr(LParenLoc, Tok.getLocation(), Result.take());
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
// Match the ')'.
if (Result.isInvalid()) {
SkipUntil(tok::r_paren);
return ExprError();
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate between a parenthesized type-id and a paren expression without considering the context past the parentheses. Behold: (T())x; - type-id (T())*x; - type-id (T())/x; - expression (T()); - expression llvm-svn: 72260
2009-05-22 18:24:42 +08:00
if (Tok.is(tok::r_paren))
RParenLoc = ConsumeParen();
else
MatchRHSPunctuation(tok::r_paren, LParenLoc);
return move(Result);
}