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

3073 lines
110 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++.
//
//===----------------------------------------------------------------------===//
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
#include "clang/AST/ASTContext.h"
When we're inside a functional cast, '>' is an operator. Fixes PR8912. llvm-svn: 123201
2011-01-11 08:33:19 +08:00
#include "RAIIObjectsForParser.h"
[cleanup] Re-sort includes with llvm/utils/sort_includes.py and fix a missing include from CLog.h. CLog.h referenced most of the core libclang types but never directly included Index.h that provides them. Previously it got lucky and other headers were always included first but with the sorting it ended up first in one case and stopped compiling. Adding the Index.h include fixes it right up. llvm-svn: 202810
2014-03-04 18:05:20 +08:00
#include "clang/AST/DeclTemplate.h"
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
#include "clang/Basic/PrettyStackTrace.h"
Fix a couple of issues with literal-operator-id parsing, and provide recovery for a few kinds of error. Specifically: Since we're after translation phase 6, the "" token might be formed by multiple source-level string literals. Checking the token width is not a correct way of detecting empty string literals, due to escaped newlines. Diagnose and recover from a missing space between "" and suffix, and from string literals other than "", which are followed by a suffix. llvm-svn: 152348
2012-03-09 07:06:02 +08:00
#include "clang/Lex/LiteralSupport.h"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "clang/Parse/ParseDiagnostic.h"
Sort all the #include lines with LLVM's utils/sort_includes.py which encodes the canonical rules for LLVM's style. I noticed this had drifted quite a bit when cleaning up LLVM, so wanted to clean up Clang as well. llvm-svn: 198686
2014-01-07 19:51:46 +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"
Sort all of Clang's files under 'lib', and fix up the broken headers uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
2012-12-04 17:13:33 +08:00
#include "clang/Sema/Scope.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"
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +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
using namespace clang;
Bring back magic constants in the digraph diagnostic This backs out changes in commit r198605 and part of r198604, replacing the original tok::kw_template with a slightly more obvious placeholder tok::unknown. llvm-svn: 198666
2014-01-07 10:35:33 +08:00
static int SelectDigraphErrorMessage(tok::TokenKind Kind) {
switch (Kind) {
// template name
case tok::unknown: return 0;
// casts
case tok::kw_const_cast: return 1;
case tok::kw_dynamic_cast: return 2;
case tok::kw_reinterpret_cast: return 3;
case tok::kw_static_cast: return 4;
default:
llvm_unreachable("Unknown type for digraph error message.");
}
}
Detect when the string "<::" is found in code after a cast or template name and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::". Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro. llvm-svn: 129540
2011-04-15 05:45:45 +08:00
// Are the two tokens adjacent in the same source file?
Extend the error recovery for a template-argument-list terminated by '>>' to also deal with '>>>' (in CUDA), '>=', and '>>='. Fix the FixItHints logic to deal with cases where the token is followed by an adjacent '=', '==', '>=', '>>=', or '>>>' token, where a naive fix-it would result in a differing token stream on a re-lex. llvm-svn: 158652
2012-06-18 14:11:04 +08:00
bool Parser::areTokensAdjacent(const Token &First, const Token &Second) {
Detect when the string "<::" is found in code after a cast or template name and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::". Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro. llvm-svn: 129540
2011-04-15 05:45:45 +08:00
SourceManager &SM = PP.getSourceManager();
SourceLocation FirstLoc = SM.getSpellingLoc(First.getLocation());
Rename SourceLocation::getFileLocWithOffset -> getLocWithOffset. It already works (and is useful with) macro locs as well. llvm-svn: 140057
2011-09-20 04:40:19 +08:00
SourceLocation FirstEnd = FirstLoc.getLocWithOffset(First.getLength());
Detect when the string "<::" is found in code after a cast or template name and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::". Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro. llvm-svn: 129540
2011-04-15 05:45:45 +08:00
return FirstEnd == SM.getSpellingLoc(Second.getLocation());
}
// Suggest fixit for "<::" after a cast.
static void FixDigraph(Parser &P, Preprocessor &PP, Token &DigraphToken,
Token &ColonToken, tok::TokenKind Kind, bool AtDigraph) {
// Pull '<:' and ':' off token stream.
if (!AtDigraph)
PP.Lex(DigraphToken);
PP.Lex(ColonToken);
SourceRange Range;
Range.setBegin(DigraphToken.getLocation());
Range.setEnd(ColonToken.getLocation());
P.Diag(DigraphToken.getLocation(), diag::err_missing_whitespace_digraph)
Bring back magic constants in the digraph diagnostic This backs out changes in commit r198605 and part of r198604, replacing the original tok::kw_template with a slightly more obvious placeholder tok::unknown. llvm-svn: 198666
2014-01-07 10:35:33 +08:00
<< SelectDigraphErrorMessage(Kind)
<< FixItHint::CreateReplacement(Range, "< ::");
Detect when the string "<::" is found in code after a cast or template name and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::". Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro. llvm-svn: 129540
2011-04-15 05:45:45 +08:00
// Update token information to reflect their change in token type.
ColonToken.setKind(tok::coloncolon);
Rename SourceLocation::getFileLocWithOffset -> getLocWithOffset. It already works (and is useful with) macro locs as well. llvm-svn: 140057
2011-09-20 04:40:19 +08:00
ColonToken.setLocation(ColonToken.getLocation().getLocWithOffset(-1));
Detect when the string "<::" is found in code after a cast or template name and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::". Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro. llvm-svn: 129540
2011-04-15 05:45:45 +08:00
ColonToken.setLength(2);
DigraphToken.setKind(tok::less);
DigraphToken.setLength(1);
// Push new tokens back to token stream.
PP.EnterToken(ColonToken);
if (!AtDigraph)
PP.EnterToken(DigraphToken);
}
Changes to the name lookup have caused a regression in the digraph fix-it hint. For instance: template <class T> void E() {}; class F {}; void test() { ::E<::F>(); E<::F>(); } Gives the following error messages: error: found '<::' after a template name which forms the digraph '<:' (aka '[') and a ':', did you mean '< ::'? ::E<::F>(); ^~~ < :: error: expected expression E<::F>(); ^ error: expected ']' note: to match this '[' E<::F>(); This patch adds the digraph fix-it check right before the name lookup, moves the shared checking code to a new function, and adds new tests to catch future regressions. llvm-svn: 140039
2011-09-20 03:01:00 +08:00
// Check for '<::' which should be '< ::' instead of '[:' when following
// a template name.
void Parser::CheckForTemplateAndDigraph(Token &Next, ParsedType ObjectType,
bool EnteringContext,
IdentifierInfo &II, CXXScopeSpec &SS) {
Fix a problem in digraph handling where "[:" might be treated as "<::" and erronously trigger the digraph correction fix-it. Include a new test to catch this in the future. llvm-svn: 140175
2011-09-21 04:03:50 +08:00
if (!Next.is(tok::l_square) || Next.getLength() != 2)
Changes to the name lookup have caused a regression in the digraph fix-it hint. For instance: template <class T> void E() {}; class F {}; void test() { ::E<::F>(); E<::F>(); } Gives the following error messages: error: found '<::' after a template name which forms the digraph '<:' (aka '[') and a ':', did you mean '< ::'? ::E<::F>(); ^~~ < :: error: expected expression E<::F>(); ^ error: expected ']' note: to match this '[' E<::F>(); This patch adds the digraph fix-it check right before the name lookup, moves the shared checking code to a new function, and adds new tests to catch future regressions. llvm-svn: 140039
2011-09-20 03:01:00 +08:00
return;
Token SecondToken = GetLookAheadToken(2);
Extend the error recovery for a template-argument-list terminated by '>>' to also deal with '>>>' (in CUDA), '>=', and '>>='. Fix the FixItHints logic to deal with cases where the token is followed by an adjacent '=', '==', '>=', '>>=', or '>>>' token, where a naive fix-it would result in a differing token stream on a re-lex. llvm-svn: 158652
2012-06-18 14:11:04 +08:00
if (!SecondToken.is(tok::colon) || !areTokensAdjacent(Next, SecondToken))
Changes to the name lookup have caused a regression in the digraph fix-it hint. For instance: template <class T> void E() {}; class F {}; void test() { ::E<::F>(); E<::F>(); } Gives the following error messages: error: found '<::' after a template name which forms the digraph '<:' (aka '[') and a ':', did you mean '< ::'? ::E<::F>(); ^~~ < :: error: expected expression E<::F>(); ^ error: expected ']' note: to match this '[' E<::F>(); This patch adds the digraph fix-it check right before the name lookup, moves the shared checking code to a new function, and adds new tests to catch future regressions. llvm-svn: 140039
2011-09-20 03:01:00 +08:00
return;
TemplateTy Template;
UnqualifiedId TemplateName;
TemplateName.setIdentifier(&II, Tok.getLocation());
bool MemberOfUnknownSpecialization;
if (!Actions.isTemplateName(getCurScope(), SS, /*hasTemplateKeyword=*/false,
TemplateName, ObjectType, EnteringContext,
Template, MemberOfUnknownSpecialization))
return;
Bring back magic constants in the digraph diagnostic This backs out changes in commit r198605 and part of r198604, replacing the original tok::kw_template with a slightly more obvious placeholder tok::unknown. llvm-svn: 198666
2014-01-07 10:35:33 +08:00
FixDigraph(*this, PP, Next, SecondToken, tok::unknown,
/*AtDigraph*/false);
Changes to the name lookup have caused a regression in the digraph fix-it hint. For instance: template <class T> void E() {}; class F {}; void test() { ::E<::F>(); E<::F>(); } Gives the following error messages: error: found '<::' after a template name which forms the digraph '<:' (aka '[') and a ':', did you mean '< ::'? ::E<::F>(); ^~~ < :: error: expected expression E<::F>(); ^ error: expected ']' note: to match this '[' E<::F>(); This patch adds the digraph fix-it check right before the name lookup, moves the shared checking code to a new function, and adds new tests to catch future regressions. llvm-svn: 140039
2011-09-20 03:01:00 +08:00
}
When finding a '(' after '::', emit error with hint to remove '(' and matching ')', if found. Don't crash. Fixes PR11852. llvm-svn: 167268
2012-11-02 09:08:58 +08:00
/// \brief Emits an error for a left parentheses after a double colon.
///
/// When a '(' is found after a '::', emit an error. Attempt to fix the token
Fix sentence construction-o. llvm-svn: 168855
2012-11-29 13:29:23 +08:00
/// stream by removing the '(', and the matching ')' if found.
When finding a '(' after '::', emit error with hint to remove '(' and matching ')', if found. Don't crash. Fixes PR11852. llvm-svn: 167268
2012-11-02 09:08:58 +08:00
void Parser::CheckForLParenAfterColonColon() {
if (!Tok.is(tok::l_paren))
return;
SourceLocation l_parenLoc = ConsumeParen(), r_parenLoc;
Token Tok1 = getCurToken();
if (!Tok1.is(tok::identifier) && !Tok1.is(tok::star))
return;
if (Tok1.is(tok::identifier)) {
Token Tok2 = GetLookAheadToken(1);
if (Tok2.is(tok::r_paren)) {
ConsumeToken();
PP.EnterToken(Tok1);
r_parenLoc = ConsumeParen();
}
} else if (Tok1.is(tok::star)) {
Token Tok2 = GetLookAheadToken(1);
if (Tok2.is(tok::identifier)) {
Token Tok3 = GetLookAheadToken(2);
if (Tok3.is(tok::r_paren)) {
ConsumeToken();
ConsumeToken();
PP.EnterToken(Tok2);
PP.EnterToken(Tok1);
r_parenLoc = ConsumeParen();
}
}
}
Diag(l_parenLoc, diag::err_paren_after_colon_colon)
<< FixItHint::CreateRemoval(l_parenLoc)
<< FixItHint::CreateRemoval(r_parenLoc);
}
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 special-case name lookup for inheriting constructors: member using-declarations with names which look constructor-like are interpreted as constructor names. llvm-svn: 177957
2013-03-26 09:15:19 +08:00
///
/// \param IsTypename If \c true, this nested-name-specifier is known to be
/// part of a type name. This is used to improve error recovery.
///
/// \param LastII When non-NULL, points to an IdentifierInfo* that will be
/// filled in with the leading identifier in the last component of the
/// nested-name-specifier, if any.
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
///
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,
Improve recovery (error + fix-it) when parsing type dependent template name without the "template" keyword. For example: typename C1<T>:: /*template*/ Iterator<0> pos; Also the error is downgraded to an ExtWarn in Microsoft mode. llvm-svn: 128387
2011-03-28 03:41:34 +08:00
bool *MayBePseudoDestructor,
Implement special-case name lookup for inheriting constructors: member using-declarations with names which look constructor-like are interpreted as constructor names. llvm-svn: 177957
2013-03-26 09:15:19 +08:00
bool IsTypename,
IdentifierInfo **LastII) {
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
assert(getLangOpts().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)) {
Implement special-case name lookup for inheriting constructors: member using-declarations with names which look constructor-like are interpreted as constructor names. llvm-svn: 177957
2013-03-26 09:15:19 +08:00
assert(!LastII && "want last identifier but have already annotated scope");
Retain complete source-location information for C++ nested-name-specifiers throughout the parser, and provide a new class (NestedNameSpecifierLoc) that contains a nested-name-specifier along with its type-source information. Right now, this information is completely useless, because we don't actually store the source-location information anywhere in the AST. Call this Step 1/N. llvm-svn: 126391
2011-02-25 01:54:50 +08:00
Actions.RestoreNestedNameSpecifierAnnotation(Tok.getAnnotationValue(),
Tok.getAnnotationRange(),
SS);
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
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
Removed hack that was used to properly restore the nested name specifier of qualified variable template ids. It turns out that the current implementation was just not logical setup for it. This commit has made it so. llvm-svn: 187776
2013-08-06 13:49:26 +08:00
if (Tok.is(tok::annot_template_id)) {
// If the current token is an annotated template id, it may already have
// a scope specifier. Restore it.
TemplateIdAnnotation *TemplateId = takeTemplateIdAnnotation(Tok);
SS = TemplateId->SS;
}
Implement special-case name lookup for inheriting constructors: member using-declarations with names which look constructor-like are interpreted as constructor names. llvm-svn: 177957
2013-03-26 09:15:19 +08:00
if (LastII)
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
*LastII = nullptr;
Implement special-case name lookup for inheriting constructors: member using-declarations with names which look constructor-like are interpreted as constructor names. llvm-svn: 177957
2013-03-26 09:15:19 +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.
-ms-extensions: Implement __super scope specifier (PR13236). We build a NestedNameSpecifier that records the CXXRecordDecl in which __super appeared. Name lookup is performed in all base classes of the recorded CXXRecordDecl. Use of __super is allowed only inside class and member function scope. llvm-svn: 218484
2014-09-26 08:28:20 +08:00
if (Actions.ActOnCXXGlobalScopeSpecifier(ConsumeToken(), SS))
Teach CXXScopeSpec to handle the extension of a nested-name-specifier with another component in the nested-name-specifiers, updating its representation (a NestedNameSpecifier) and source-location information (currently a SourceRange) simultaneously. This is groundwork for adding source-location information to nested-name-specifiers. llvm-svn: 126346
2011-02-24 08:17:56 +08:00
return true;
When finding a '(' after '::', emit error with hint to remove '(' and matching ')', if found. Don't crash. Fixes PR11852. llvm-svn: 167268
2012-11-02 09:08:58 +08:00
CheckForLParenAfterColonColon();
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
}
-ms-extensions: Implement __super scope specifier (PR13236). We build a NestedNameSpecifier that records the CXXRecordDecl in which __super appeared. Name lookup is performed in all base classes of the recorded CXXRecordDecl. Use of __super is allowed only inside class and member function scope. llvm-svn: 218484
2014-09-26 08:28:20 +08:00
if (Tok.is(tok::kw___super)) {
SourceLocation SuperLoc = ConsumeToken();
if (!Tok.is(tok::coloncolon)) {
Diag(Tok.getLocation(), diag::err_expected_coloncolon_after_super);
return true;
}
return Actions.ActOnSuperScopeSpecifier(SuperLoc, ConsumeToken(), SS);
}
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;
}
PR20991: ::decltype is not valid. llvm-svn: 219043
2014-10-04 09:57:39 +08:00
if (!HasScopeSpecifier &&
(Tok.is(tok::kw_decltype) || Tok.is(tok::annot_decltype))) {
Support decltype in nested-name-specifiers. llvm-svn: 145785
2011-12-04 13:04:18 +08:00
DeclSpec DS(AttrFactory);
SourceLocation DeclLoc = Tok.getLocation();
SourceLocation EndLoc = ParseDecltypeSpecifier(DS);
Refactor and micro-optimize ConsumeToken() 1) Introduce TryConsumeToken() to handle the common test-and-consume pattern. This brings about readability improvements in the parser and optimizes to avoid redundant checks in the common case. 2) Eliminate the ConsumeCodeCompletionTok special case from ConsumeToken(). This was used by only one caller which has been switched over to the more appropriate ConsumeCodeCompletionToken() function. llvm-svn: 197497
2013-12-17 22:12:37 +08:00
SourceLocation CCLoc;
if (!TryConsumeToken(tok::coloncolon, CCLoc)) {
Support decltype in nested-name-specifiers. llvm-svn: 145785
2011-12-04 13:04:18 +08:00
AnnotateExistingDecltypeSpecifier(DS, DeclLoc, EndLoc);
return false;
}
Refactor and micro-optimize ConsumeToken() 1) Introduce TryConsumeToken() to handle the common test-and-consume pattern. This brings about readability improvements in the parser and optimizes to avoid redundant checks in the common case. 2) Eliminate the ConsumeCodeCompletionTok special case from ConsumeToken(). This was used by only one caller which has been switched over to the more appropriate ConsumeCodeCompletionToken() function. llvm-svn: 197497
2013-12-17 22:12:37 +08:00
Support decltype in nested-name-specifiers. llvm-svn: 145785
2011-12-04 13:04:18 +08:00
if (Actions.ActOnCXXNestedNameSpecifierDecltype(SS, DS, CCLoc))
SS.SetInvalid(SourceRange(DeclLoc, CCLoc));
HasScopeSpecifier = true;
}
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);
Fix an assertion when code-completing, rdar://9288730 & http://llvm.org/PR9728. llvm-svn: 130042
2011-04-23 09:04:12 +08:00
// Include code completion token into the range of the scope otherwise
// when we try to annotate the scope tokens the dangling code completion
// token will cause assertion in
// Preprocessor::AnnotatePreviousCachedTokens.
Support code-completion for C++ inline methods and ObjC buffering methods. Previously we would cut off the source file buffer at the code-completion point; this impeded code-completion inside C++ inline methods and, recently, with buffering ObjC methods. Have the code-completion inserted into the source buffer so that it can be buffered along with a method body. When we actually hit the code-completion point the cut-off lexing or parsing. Fixes rdar://10056932&8319466 llvm-svn: 139086
2011-09-04 11:32:15 +08:00
SS.setEndLoc(Tok.getLocation());
cutOffParsing();
return true;
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();
Reject template-ids containing literal-operator-ids that have a dependent nested-name-specifier, rather than crashing. (In fact, reject all literal-operator-ids that have a non-namespace nested-name-specifier). The grammar doesn't allow these in some cases, and in other cases does allow them but instantiation will always fail. llvm-svn: 196443
2013-12-05 08:58:33 +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
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)) {
Reject template-ids containing literal-operator-ids that have a dependent nested-name-specifier, rather than crashing. (In fact, reject all literal-operator-ids that have a non-namespace nested-name-specifier). The grammar doesn't allow these in some cases, and in other cases does allow them but instantiation will always fail. llvm-svn: 196443
2013-12-05 08:58:33 +08:00
// We don't need to actually parse the unqualified-id in this case,
// because a simple-template-id cannot start with 'operator', but
// go ahead and parse it anyway for consistency with the case where
// we already annotated the template-id.
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
}
Reject template-ids containing literal-operator-ids that have a dependent nested-name-specifier, rather than crashing. (In fact, reject all literal-operator-ids that have a non-namespace nested-name-specifier). The grammar doesn't allow these in some cases, and in other cases does allow them but instantiation will always fail. llvm-svn: 196443
2013-12-05 08:58:33 +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;
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
if (TemplateNameKind TNK
= Actions.ActOnDependentTemplateName(getCurScope(),
SS, TemplateKWLoc, TemplateName,
ObjectType, EnteringContext,
Template)) {
if (AnnotateTemplateIdToken(Template, TNK, SS, TemplateKWLoc,
TemplateName, false))
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
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
//
Fix several crash-on-invalids when using template-ids that aren't simple-template-ids (eg, 'operator+<int>') in weird places. llvm-svn: 196333
2013-12-04 08:28:23 +08:00
// template-id '::'
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
//
Fix several crash-on-invalids when using template-ids that aren't simple-template-ids (eg, 'operator+<int>') in weird places. llvm-svn: 196333
2013-12-04 08:28:23 +08:00
// So we need to check whether the template-id is a simple-template-id of
// the right kind (it should name a type or be dependent), and then
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
// convert it into a type within the nested-name-specifier.
Introduce DelayedCleanupPool useful for simplifying clean-up of certain resources that, while their lifetime is well-known and restricted, cleaning them up manually is easy to miss and cause a leak. Use it to plug the leaking of TemplateIdAnnotation objects. rdar://9634138. llvm-svn: 133610
2011-06-22 14:09:49 +08:00
TemplateIdAnnotation *TemplateId = takeTemplateIdAnnotation(Tok);
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
}
Implement special-case name lookup for inheriting constructors: member using-declarations with names which look constructor-like are interpreted as constructor names. llvm-svn: 177957
2013-03-26 09:15:19 +08:00
if (LastII)
*LastII = TemplateId->Name;
Teach Sema::ActOnCXXNestedNameSpecifier and Sema::CheckTemplateIdType to cope with non-type templates by providing appropriate errors. Previously, we would either assert, crash, or silently build a dependent type when we shouldn't. Fixes PR9226. llvm-svn: 127037
2011-03-05 05:37:14 +08:00
// Consume the template-id token.
ConsumeToken();
Improve error recovery around colon. Parse of nested name spacifier is modified so that it properly recovers if colon is mistyped as double colon in case statement. This patch fixes PR15133. Differential Revision: http://llvm-reviews.chandlerc.com/D2870 llvm-svn: 206135
2014-04-14 00:52:03 +08:00
Teach Sema::ActOnCXXNestedNameSpecifier and Sema::CheckTemplateIdType to cope with non-type templates by providing appropriate errors. Previously, we would either assert, crash, or silently build a dependent type when we shouldn't. Fixes PR9226. llvm-svn: 127037
2011-03-05 05:37:14 +08:00
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
Remove duplicate word & unnecessary conditional. llvm-svn: 143907
2011-11-07 11:30:03 +08:00
HasScopeSpecifier = true;
Improve error recovery around colon. Parse of nested name spacifier is modified so that it properly recovers if colon is mistyped as double colon in case statement. This patch fixes PR15133. Differential Revision: http://llvm-reviews.chandlerc.com/D2870 llvm-svn: 206135
2014-04-14 00:52:03 +08:00
Now that ASTMultiPtr is nothing more than a array reference, make it a MutableArrayRef. This required changing all get() calls to data() and using the simpler constructors. llvm-svn: 162501
2012-08-24 07:38:35 +08:00
ASTTemplateArgsPtr TemplateArgsPtr(TemplateId->getTemplateArgs(),
Teach Sema::ActOnCXXNestedNameSpecifier and Sema::CheckTemplateIdType to cope with non-type templates by providing appropriate errors. Previously, we would either assert, crash, or silently build a dependent type when we shouldn't. Fixes PR9226. llvm-svn: 127037
2011-03-05 05:37:14 +08:00
TemplateId->NumArgs);
Improve error recovery around colon. Parse of nested name spacifier is modified so that it properly recovers if colon is mistyped as double colon in case statement. This patch fixes PR15133. Differential Revision: http://llvm-reviews.chandlerc.com/D2870 llvm-svn: 206135
2014-04-14 00:52:03 +08:00
Teach Sema::ActOnCXXNestedNameSpecifier and Sema::CheckTemplateIdType to cope with non-type templates by providing appropriate errors. Previously, we would either assert, crash, or silently build a dependent type when we shouldn't. Fixes PR9226. llvm-svn: 127037
2011-03-05 05:37:14 +08:00
if (Actions.ActOnCXXNestedNameSpecifier(getCurScope(),
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
SS,
TemplateId->TemplateKWLoc,
Teach Sema::ActOnCXXNestedNameSpecifier and Sema::CheckTemplateIdType to cope with non-type templates by providing appropriate errors. Previously, we would either assert, crash, or silently build a dependent type when we shouldn't. Fixes PR9226. llvm-svn: 127037
2011-03-05 05:37:14 +08:00
TemplateId->Template,
TemplateId->TemplateNameLoc,
TemplateId->LAngleLoc,
TemplateArgsPtr,
TemplateId->RAngleLoc,
CCLoc,
EnteringContext)) {
SourceLocation StartLoc
= SS.getBeginLoc().isValid()? SS.getBeginLoc()
: TemplateId->TemplateNameLoc;
SS.SetInvalid(SourceRange(StartLoc, CCLoc));
simplify some code. llvm-svn: 74259
2009-06-26 11:45:46 +08:00
}
Fix a double free when parsing malformed code. Fixes rdar://9173693. llvm-svn: 130775
2011-05-04 02:45:38 +08:00
Teach Sema::ActOnCXXNestedNameSpecifier and Sema::CheckTemplateIdType to cope with non-type templates by providing appropriate errors. Previously, we would either assert, crash, or silently build a dependent type when we shouldn't. Fixes PR9226. llvm-svn: 127037
2011-03-05 05:37:14 +08:00
continue;
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) {
Teach CXXScopeSpec to handle the extension of a nested-name-specifier with another component in the nested-name-specifiers, updating its representation (a NestedNameSpecifier) and source-location information (currently a SourceRange) simultaneously. This is groundwork for adding source-location information to nested-name-specifiers. llvm-svn: 126346
2011-02-24 08:17:56 +08:00
if (Actions.IsInvalidUnlessNestedName(getCurScope(), SS, II,
Tok.getLocation(),
Next.getLocation(), 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)) {
Improve error recovery around colon. Parse of nested name spacifier is modified so that it properly recovers if colon is mistyped as double colon in case statement. This patch fixes PR15133. Differential Revision: http://llvm-reviews.chandlerc.com/D2870 llvm-svn: 206135
2014-04-14 00:52:03 +08:00
Diag(Next, diag::err_unexpected_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) &&
Wrap to 80 columns, no functionality change. llvm-svn: 214036
2014-07-27 06:15:25 +08:00
!Actions.isNonTypeNestedNameSpecifier(
getCurScope(), SS, Tok.getLocation(), 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
}
Improve error recovery around colon. Parse of nested name spacifier is modified so that it properly recovers if colon is mistyped as double colon in case statement. This patch fixes PR15133. Differential Revision: http://llvm-reviews.chandlerc.com/D2870 llvm-svn: 206135
2014-04-14 00:52:03 +08:00
if (ColonIsSacred) {
const Token &Next2 = GetLookAheadToken(2);
if (Next2.is(tok::kw_private) || Next2.is(tok::kw_protected) ||
Next2.is(tok::kw_public) || Next2.is(tok::kw_virtual)) {
Diag(Next2, diag::err_unexpected_token_in_nested_name_spec)
<< Next2.getName()
<< FixItHint::CreateReplacement(Next.getLocation(), ":");
Token ColonColon;
PP.Lex(ColonColon);
ColonColon.setKind(tok::colon);
PP.EnterToken(ColonColon);
break;
}
}
Implement special-case name lookup for inheriting constructors: member using-declarations with names which look constructor-like are interpreted as constructor names. llvm-svn: 177957
2013-03-26 09:15:19 +08:00
if (LastII)
*LastII = &II;
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.
Improve error recovery around colon. Parse of nested name spacifier is modified so that it properly recovers if colon is mistyped as double colon in case statement. This patch fixes PR15133. Differential Revision: http://llvm-reviews.chandlerc.com/D2870 llvm-svn: 206135
2014-04-14 00:52:03 +08:00
Token Identifier = Tok;
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
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!");
Improve error recovery around colon. Parse of nested name spacifier is modified so that it properly recovers if colon is mistyped as double colon in case statement. This patch fixes PR15133. Differential Revision: http://llvm-reviews.chandlerc.com/D2870 llvm-svn: 206135
2014-04-14 00:52:03 +08:00
Token ColonColon = Tok;
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
When finding a '(' after '::', emit error with hint to remove '(' and matching ')', if found. Don't crash. Fixes PR11852. llvm-svn: 167268
2012-11-02 09:08:58 +08:00
CheckForLParenAfterColonColon();
Improve error recovery around colon. Parse of nested name spacifier is modified so that it properly recovers if colon is mistyped as double colon in case statement. This patch fixes PR15133. Differential Revision: http://llvm-reviews.chandlerc.com/D2870 llvm-svn: 206135
2014-04-14 00:52:03 +08:00
bool IsCorrectedToColon = false;
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
bool *CorrectionFlagPtr = ColonIsSacred ? &IsCorrectedToColon : nullptr;
Teach CXXScopeSpec to handle the extension of a nested-name-specifier with another component in the nested-name-specifiers, updating its representation (a NestedNameSpecifier) and source-location information (currently a SourceRange) simultaneously. This is groundwork for adding source-location information to nested-name-specifiers. llvm-svn: 126346
2011-02-24 08:17:56 +08:00
if (Actions.ActOnCXXNestedNameSpecifier(getCurScope(), II, IdLoc, CCLoc,
Improve error recovery around colon. Parse of nested name spacifier is modified so that it properly recovers if colon is mistyped as double colon in case statement. This patch fixes PR15133. Differential Revision: http://llvm-reviews.chandlerc.com/D2870 llvm-svn: 206135
2014-04-14 00:52:03 +08:00
ObjectType, EnteringContext, SS,
false, CorrectionFlagPtr)) {
// Identifier is not recognized as a nested name, but we can have
// mistyped '::' instead of ':'.
if (CorrectionFlagPtr && IsCorrectedToColon) {
ColonColon.setKind(tok::colon);
PP.EnterToken(Tok);
PP.EnterToken(ColonColon);
Tok = Identifier;
break;
}
Teach CXXScopeSpec to handle the extension of a nested-name-specifier with another component in the nested-name-specifiers, updating its representation (a NestedNameSpecifier) and source-location information (currently a SourceRange) simultaneously. This is groundwork for adding source-location information to nested-name-specifiers. llvm-svn: 126346
2011-02-24 08:17:56 +08:00
SS.SetInvalid(SourceRange(IdLoc, CCLoc));
Improve error recovery around colon. Parse of nested name spacifier is modified so that it properly recovers if colon is mistyped as double colon in case statement. This patch fixes PR15133. Differential Revision: http://llvm-reviews.chandlerc.com/D2870 llvm-svn: 206135
2014-04-14 00:52:03 +08:00
}
HasScopeSpecifier = true;
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
continue;
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Changes to the name lookup have caused a regression in the digraph fix-it hint. For instance: template <class T> void E() {}; class F {}; void test() { ::E<::F>(); E<::F>(); } Gives the following error messages: error: found '<::' after a template name which forms the digraph '<:' (aka '[') and a ':', did you mean '< ::'? ::E<::F>(); ^~~ < :: error: expected expression E<::F>(); ^ error: expected ']' note: to match this '[' E<::F>(); This patch adds the digraph fix-it check right before the name lookup, moves the shared checking code to a new function, and adds new tests to catch future regressions. llvm-svn: 140039
2011-09-20 03:01:00 +08:00
CheckForTemplateAndDigraph(Next, ObjectType, EnteringContext, II, SS);
Detect when the string "<::" is found in code after a cast or template name and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::". Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro. llvm-svn: 129540
2011-04-15 05:45:45 +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)) {
Remove duplicate word & unnecessary conditional. llvm-svn: 143907
2011-11-07 11:30:03 +08:00
// We have found a template name, so annotate this token
rearrange more code, this avoids a token lookahead for foo< llvm-svn: 74261
2009-06-26 11:52:38 +08:00
// 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();
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
if (AnnotateTemplateIdToken(Template, TNK, SS, SourceLocation(),
TemplateName, 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;
Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention... llvm-svn: 187762
2013-08-06 09:03:05 +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
if (MemberOfUnknownSpecialization && (ObjectType || SS.isSet()) &&
Improve recovery (error + fix-it) when parsing type dependent template name without the "template" keyword. For example: typename C1<T>:: /*template*/ Iterator<0> pos; Also the error is downgraded to an ExtWarn in Microsoft mode. llvm-svn: 128387
2011-03-28 03:41:34 +08:00
(IsTypename || IsTemplateArgumentList(1))) {
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
// 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.
Improve recovery (error + fix-it) when parsing type dependent template name without the "template" keyword. For example: typename C1<T>:: /*template*/ Iterator<0> pos; Also the error is downgraded to an ExtWarn in Microsoft mode. llvm-svn: 128387
2011-03-28 03:41:34 +08:00
unsigned DiagID = diag::err_missing_dependent_template_keyword;
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (getLangOpts().MicrosoftExt)
For consistency, change suffix from war_ to warn_ for some Microsoft warnings I introduced lately. llvm-svn: 129986
2011-04-22 16:25:24 +08:00
DiagID = diag::warn_missing_dependent_template_keyword;
Improve recovery (error + fix-it) when parsing type dependent template name without the "template" keyword. For example: typename C1<T>:: /*template*/ Iterator<0> pos; Also the error is downgraded to an ExtWarn in Microsoft mode. llvm-svn: 128387
2011-03-28 03:41:34 +08:00
Diag(Tok.getLocation(), DiagID)
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
<< 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(),
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
SS, SourceLocation(),
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)) {
// Consume the identifier.
ConsumeToken();
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
if (AnnotateTemplateIdToken(Template, TNK, SS, SourceLocation(),
TemplateName, false))
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
}
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;
Tighten up the conditions under which we consider ourselves to be entering the context of a nested-name-specifier. Fixes <rdar://problem/10397846>. llvm-svn: 143967
2011-11-08 01:33:42 +08:00
ParseOptionalCXXScopeSpecifier(SS, ParsedType(), /*EnteringContext=*/false);
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
SourceLocation TemplateKWLoc;
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;
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
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(),
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
TemplateKWLoc,
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;
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
return Actions.ActOnIdExpression(getCurScope(), SS, TemplateKWLoc, Name,
Tok.is(tok::l_paren), 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
}
C++1y n3648: parse and reject init-captures for now. llvm-svn: 181553
2013-05-10 05:36:41 +08:00
/// ParseLambdaExpression - Parse a C++11 lambda expression.
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
///
/// lambda-expression:
/// lambda-introducer lambda-declarator[opt] compound-statement
///
/// lambda-introducer:
/// '[' lambda-capture[opt] ']'
///
/// lambda-capture:
/// capture-default
/// capture-list
/// capture-default ',' capture-list
///
/// capture-default:
/// '&'
/// '='
///
/// capture-list:
/// capture
/// capture-list ',' capture
///
/// capture:
C++1y n3648: parse and reject init-captures for now. llvm-svn: 181553
2013-05-10 05:36:41 +08:00
/// simple-capture
/// init-capture [C++1y]
///
/// simple-capture:
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
/// identifier
/// '&' identifier
/// 'this'
///
C++1y n3648: parse and reject init-captures for now. llvm-svn: 181553
2013-05-10 05:36:41 +08:00
/// init-capture: [C++1y]
/// identifier initializer
/// '&' identifier initializer
///
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
/// lambda-declarator:
/// '(' parameter-declaration-clause ')' attribute-specifier[opt]
/// 'mutable'[opt] exception-specification[opt]
/// trailing-return-type[opt]
///
ExprResult Parser::ParseLambdaExpression() {
// Parse lambda-introducer.
LambdaIntroducer Intro;
Fix init-captures for generic lambdas. For an init capture, process the initialization expression right away. For lambda init-captures such as the following: const int x = 10; auto L = [i = x+1](int a) { return [j = x+2, &k = x](char b) { }; }; keep in mind that each lambda init-capture has to have: - its initialization expression executed in the context of the enclosing/parent decl-context. - but the variable itself has to be 'injected' into the decl-context of its lambda's call-operator (which has not yet been created). Each init-expression is a full-expression that has to get Sema-analyzed (for capturing etc.) before its lambda's call-operator's decl-context, scope & scopeinfo are pushed on their respective stacks. Thus if any variable is odr-used in the init-capture it will correctly get captured in the enclosing lambda, if one exists. The init-variables above are created later once the lambdascope and call-operators decl-context is pushed onto its respective stack. Since the lambda init-capture's initializer expression occurs in the context of the enclosing function or lambda, therefore we can not wait till a lambda scope has been pushed on before deciding whether the variable needs to be captured. We also need to process all lvalue-to-rvalue conversions and discarded-value conversions, so that we can avoid capturing certain constant variables. For e.g., void test() { const int x = 10; auto L = [&z = x](char a) { <-- don't capture by the current lambda return [y = x](int i) { <-- don't capture by enclosing lambda return y; } }; If x was not const, the second use would require 'L' to capture, and that would be an error. Make sure TranformLambdaExpr is also aware of this. Patch approved by Richard (Thanks!!) http://llvm-reviews.chandlerc.com/D2092 llvm-svn: 196454
2013-12-05 09:40:41 +08:00
Optional<unsigned> DiagID = ParseLambdaIntroducer(Intro);
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
if (DiagID) {
Diag(Tok, DiagID.getValue());
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::r_square, StopAtSemi);
SkipUntil(tok::l_brace, StopAtSemi);
SkipUntil(tok::r_brace, StopAtSemi);
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
return ExprError();
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
}
return ParseLambdaExpressionAfterIntroducer(Intro);
}
/// TryParseLambdaExpression - Use lookahead and potentially tentative
/// parsing to determine if we are looking at a C++0x lambda expression, and parse
/// it if we are.
///
/// If we are not looking at a lambda expression, returns ExprError().
ExprResult Parser::TryParseLambdaExpression() {
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
assert(getLangOpts().CPlusPlus11
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
&& Tok.is(tok::l_square)
&& "Not at the start of a possible lambda expression.");
const Token Next = NextToken(), After = GetLookAheadToken(2);
// If lookahead indicates this is a lambda...
if (Next.is(tok::r_square) || // []
Next.is(tok::equal) || // [=
(Next.is(tok::amp) && // [&] or [&,
(After.is(tok::r_square) ||
After.is(tok::comma))) ||
(Next.is(tok::identifier) && // [identifier]
After.is(tok::r_square))) {
return ParseLambdaExpression();
}
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
// If lookahead indicates an ObjC message send...
// [identifier identifier
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
if (Next.is(tok::identifier) && After.is(tok::identifier)) {
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
return ExprEmpty();
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
}
Fix init-captures for generic lambdas. For an init capture, process the initialization expression right away. For lambda init-captures such as the following: const int x = 10; auto L = [i = x+1](int a) { return [j = x+2, &k = x](char b) { }; }; keep in mind that each lambda init-capture has to have: - its initialization expression executed in the context of the enclosing/parent decl-context. - but the variable itself has to be 'injected' into the decl-context of its lambda's call-operator (which has not yet been created). Each init-expression is a full-expression that has to get Sema-analyzed (for capturing etc.) before its lambda's call-operator's decl-context, scope & scopeinfo are pushed on their respective stacks. Thus if any variable is odr-used in the init-capture it will correctly get captured in the enclosing lambda, if one exists. The init-variables above are created later once the lambdascope and call-operators decl-context is pushed onto its respective stack. Since the lambda init-capture's initializer expression occurs in the context of the enclosing function or lambda, therefore we can not wait till a lambda scope has been pushed on before deciding whether the variable needs to be captured. We also need to process all lvalue-to-rvalue conversions and discarded-value conversions, so that we can avoid capturing certain constant variables. For e.g., void test() { const int x = 10; auto L = [&z = x](char a) { <-- don't capture by the current lambda return [y = x](int i) { <-- don't capture by enclosing lambda return y; } }; If x was not const, the second use would require 'L' to capture, and that would be an error. Make sure TranformLambdaExpr is also aware of this. Patch approved by Richard (Thanks!!) http://llvm-reviews.chandlerc.com/D2092 llvm-svn: 196454
2013-12-05 09:40:41 +08:00
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
// Here, we're stuck: lambda introducers and Objective-C message sends are
// unambiguous, but it requires arbitrary lookhead. [a,b,c,d,e,f,g] is a
// lambda, and [a,b,c,d,e,f,g h] is a Objective-C message send. Instead of
// writing two routines to parse a lambda introducer, just try to parse
// a lambda introducer first, and fall back if that fails.
// (TryParseLambdaIntroducer never produces any diagnostic output.)
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
LambdaIntroducer Intro;
if (TryParseLambdaIntroducer(Intro))
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
return ExprEmpty();
Fix init-captures for generic lambdas. For an init capture, process the initialization expression right away. For lambda init-captures such as the following: const int x = 10; auto L = [i = x+1](int a) { return [j = x+2, &k = x](char b) { }; }; keep in mind that each lambda init-capture has to have: - its initialization expression executed in the context of the enclosing/parent decl-context. - but the variable itself has to be 'injected' into the decl-context of its lambda's call-operator (which has not yet been created). Each init-expression is a full-expression that has to get Sema-analyzed (for capturing etc.) before its lambda's call-operator's decl-context, scope & scopeinfo are pushed on their respective stacks. Thus if any variable is odr-used in the init-capture it will correctly get captured in the enclosing lambda, if one exists. The init-variables above are created later once the lambdascope and call-operators decl-context is pushed onto its respective stack. Since the lambda init-capture's initializer expression occurs in the context of the enclosing function or lambda, therefore we can not wait till a lambda scope has been pushed on before deciding whether the variable needs to be captured. We also need to process all lvalue-to-rvalue conversions and discarded-value conversions, so that we can avoid capturing certain constant variables. For e.g., void test() { const int x = 10; auto L = [&z = x](char a) { <-- don't capture by the current lambda return [y = x](int i) { <-- don't capture by enclosing lambda return y; } }; If x was not const, the second use would require 'L' to capture, and that would be an error. Make sure TranformLambdaExpr is also aware of this. Patch approved by Richard (Thanks!!) http://llvm-reviews.chandlerc.com/D2092 llvm-svn: 196454
2013-12-05 09:40:41 +08:00
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
return ParseLambdaExpressionAfterIntroducer(Intro);
}
PR16094: I should have known Obj-C init-capture disambiguation couldn't be *that* easy... Try a bit harder to disambiguate. This is mostly straightforward, but for =-style initializers, we actually need to know where an expression ends: [foo = bar baz] is a message send, whereas [foo = bar + baz] is a lambda-introducer. Handle this by parsing the expression eagerly, and replacing it with an annotation token. By chance, we use the *exact same* parsing rules in both cases (except that we need to assume we're inside a message send for the parse, to turn off various forms of inapplicable error recovery). llvm-svn: 182432
2013-05-22 06:21:19 +08:00
/// \brief Parse a lambda introducer.
/// \param Intro A LambdaIntroducer filled in with information about the
/// contents of the lambda-introducer.
/// \param SkippedInits If non-null, we are disambiguating between an Obj-C
/// message send and a lambda expression. In this mode, we will
/// sometimes skip the initializers for init-captures and not fully
/// populate \p Intro. This flag will be set to \c true if we do so.
/// \return A DiagnosticID if it hit something unexpected. The location for
/// for the diagnostic is that of the current token.
Optional<unsigned> Parser::ParseLambdaIntroducer(LambdaIntroducer &Intro,
bool *SkippedInits) {
Include llvm::Optional in clang/Basic/LLVM.h Post-commit CR feedback from Jordan Rose regarding r175594. llvm-svn: 175679
2013-02-21 06:23:23 +08:00
typedef Optional<unsigned> DiagResult;
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
assert(Tok.is(tok::l_square) && "Lambda expressions begin with '['.");
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_square);
T.consumeOpen();
Intro.Range.setBegin(T.getOpenLocation());
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
bool first = true;
// Parse capture-default.
if (Tok.is(tok::amp) &&
(NextToken().is(tok::comma) || NextToken().is(tok::r_square))) {
Intro.Default = LCD_ByRef;
Allow implicit capture of 'this' in a lambda even when the capture default is '=', and reword the warning about explicitly capturing 'this' in such lambdas to indicate that only explicit capture is banned. Introduce Fix-Its for this and other "save the programmer from themself" rules regarding what can be explicitly captured and what must be implicitly captured. llvm-svn: 150256
2012-02-11 01:46:20 +08:00
Intro.DefaultLoc = ConsumeToken();
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
first = false;
} else if (Tok.is(tok::equal)) {
Intro.Default = LCD_ByCopy;
Allow implicit capture of 'this' in a lambda even when the capture default is '=', and reword the warning about explicitly capturing 'this' in such lambdas to indicate that only explicit capture is banned. Introduce Fix-Its for this and other "save the programmer from themself" rules regarding what can be explicitly captured and what must be implicitly captured. llvm-svn: 150256
2012-02-11 01:46:20 +08:00
Intro.DefaultLoc = ConsumeToken();
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
first = false;
}
while (Tok.isNot(tok::r_square)) {
if (!first) {
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
if (Tok.isNot(tok::comma)) {
When we encounter a code-completion token while parsing an ill-formed lambda-introducer in Objective-C++11, fall back to treating the tokens as an Objective-C message send to provide those (more likely) completions. Fixes <rdar://problem/11980263>. llvm-svn: 161015
2012-07-31 08:50:07 +08:00
// Provide a completion for a lambda introducer here. Except
// in Objective-C, where this is Almost Surely meant to be a message
// send. In that case, fail here and let the ObjC message
// expression parser perform the completion.
Tweak code-completion heuristics deciding between a lambda code-completion and an Objective-C message send, based on Jordan's feedback. llvm-svn: 161049
2012-07-31 23:27:48 +08:00
if (Tok.is(tok::code_completion) &&
!(getLangOpts().ObjC1 && Intro.Default == LCD_None &&
!Intro.Captures.empty())) {
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
Actions.CodeCompleteLambdaIntroducer(getCurScope(), Intro,
/*AfterAmpersand=*/false);
Cut off parsing early during code completion These calls to ConsumeCodeCompletionToken() caused parsing to continue needlessly when an immediate cutOffParsing() would do. Document the function to clarify its correct usage. llvm-svn: 207823
2014-05-02 11:43:14 +08:00
cutOffParsing();
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
break;
}
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
return DiagResult(diag::err_expected_comma_or_rsquare);
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
}
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
ConsumeToken();
}
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
if (Tok.is(tok::code_completion)) {
// If we're in Objective-C++ and we have a bare '[', then this is more
// likely to be a message receiver.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (getLangOpts().ObjC1 && first)
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
Actions.CodeCompleteObjCMessageReceiver(getCurScope());
else
Actions.CodeCompleteLambdaIntroducer(getCurScope(), Intro,
/*AfterAmpersand=*/false);
Cut off parsing early during code completion These calls to ConsumeCodeCompletionToken() caused parsing to continue needlessly when an immediate cutOffParsing() would do. Document the function to clarify its correct usage. llvm-svn: 207823
2014-05-02 11:43:14 +08:00
cutOffParsing();
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
break;
}
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
first = false;
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
// Parse capture.
LambdaCaptureKind Kind = LCK_ByCopy;
SourceLocation Loc;
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
IdentifierInfo *Id = nullptr;
Implement support for lambda capture pack expansions, e.g., [&values...] { print(values...); } llvm-svn: 150497
2012-02-15 03:27:52 +08:00
SourceLocation EllipsisLoc;
C++1y n3648: parse and reject init-captures for now. llvm-svn: 181553
2013-05-10 05:36:41 +08:00
ExprResult Init;
Implement support for lambda capture pack expansions, e.g., [&values...] { print(values...); } llvm-svn: 150497
2012-02-15 03:27:52 +08:00
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
if (Tok.is(tok::kw_this)) {
Kind = LCK_This;
Loc = ConsumeToken();
} else {
if (Tok.is(tok::amp)) {
Kind = LCK_ByRef;
ConsumeToken();
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
if (Tok.is(tok::code_completion)) {
Actions.CodeCompleteLambdaIntroducer(getCurScope(), Intro,
/*AfterAmpersand=*/true);
Cut off parsing early during code completion These calls to ConsumeCodeCompletionToken() caused parsing to continue needlessly when an immediate cutOffParsing() would do. Document the function to clarify its correct usage. llvm-svn: 207823
2014-05-02 11:43:14 +08:00
cutOffParsing();
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
break;
}
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
}
if (Tok.is(tok::identifier)) {
Id = Tok.getIdentifierInfo();
Loc = ConsumeToken();
} else if (Tok.is(tok::kw_this)) {
// FIXME: If we want to suggest a fixit here, will need to return more
// than just DiagnosticID. Perhaps full DiagnosticBuilder that can be
// Clear()ed to prevent emission in case of tentative parsing?
return DiagResult(diag::err_this_captured_by_reference);
} else {
return DiagResult(diag::err_expected_capture);
}
C++1y n3648: parse and reject init-captures for now. llvm-svn: 181553
2013-05-10 05:36:41 +08:00
if (Tok.is(tok::l_paren)) {
BalancedDelimiterTracker Parens(*this, tok::l_paren);
Parens.consumeOpen();
ExprVector Exprs;
CommaLocsTy Commas;
PR16094: I should have known Obj-C init-capture disambiguation couldn't be *that* easy... Try a bit harder to disambiguate. This is mostly straightforward, but for =-style initializers, we actually need to know where an expression ends: [foo = bar baz] is a message send, whereas [foo = bar + baz] is a lambda-introducer. Handle this by parsing the expression eagerly, and replacing it with an annotation token. By chance, we use the *exact same* parsing rules in both cases (except that we need to assume we're inside a message send for the parse, to turn off various forms of inapplicable error recovery). llvm-svn: 182432
2013-05-22 06:21:19 +08:00
if (SkippedInits) {
Parens.skipToEnd();
*SkippedInits = true;
} else if (ParseExpressionList(Exprs, Commas)) {
C++1y n3648: parse and reject init-captures for now. llvm-svn: 181553
2013-05-10 05:36:41 +08:00
Parens.skipToEnd();
Init = ExprError();
} else {
Parens.consumeClose();
Init = Actions.ActOnParenListExpr(Parens.getOpenLocation(),
Parens.getCloseLocation(),
Exprs);
}
} else if (Tok.is(tok::l_brace) || Tok.is(tok::equal)) {
Fix init-captures for generic lambdas. For an init capture, process the initialization expression right away. For lambda init-captures such as the following: const int x = 10; auto L = [i = x+1](int a) { return [j = x+2, &k = x](char b) { }; }; keep in mind that each lambda init-capture has to have: - its initialization expression executed in the context of the enclosing/parent decl-context. - but the variable itself has to be 'injected' into the decl-context of its lambda's call-operator (which has not yet been created). Each init-expression is a full-expression that has to get Sema-analyzed (for capturing etc.) before its lambda's call-operator's decl-context, scope & scopeinfo are pushed on their respective stacks. Thus if any variable is odr-used in the init-capture it will correctly get captured in the enclosing lambda, if one exists. The init-variables above are created later once the lambdascope and call-operators decl-context is pushed onto its respective stack. Since the lambda init-capture's initializer expression occurs in the context of the enclosing function or lambda, therefore we can not wait till a lambda scope has been pushed on before deciding whether the variable needs to be captured. We also need to process all lvalue-to-rvalue conversions and discarded-value conversions, so that we can avoid capturing certain constant variables. For e.g., void test() { const int x = 10; auto L = [&z = x](char a) { <-- don't capture by the current lambda return [y = x](int i) { <-- don't capture by enclosing lambda return y; } }; If x was not const, the second use would require 'L' to capture, and that would be an error. Make sure TranformLambdaExpr is also aware of this. Patch approved by Richard (Thanks!!) http://llvm-reviews.chandlerc.com/D2092 llvm-svn: 196454
2013-12-05 09:40:41 +08:00
// Each lambda init-capture forms its own full expression, which clears
// Actions.MaybeODRUseExprs. So create an expression evaluation context
// to save the necessary state, and restore it later.
EnterExpressionEvaluationContext EC(Actions,
Sema::PotentiallyEvaluated);
Refactor and micro-optimize ConsumeToken() 1) Introduce TryConsumeToken() to handle the common test-and-consume pattern. This brings about readability improvements in the parser and optimizes to avoid redundant checks in the common case. 2) Eliminate the ConsumeCodeCompletionTok special case from ConsumeToken(). This was used by only one caller which has been switched over to the more appropriate ConsumeCodeCompletionToken() function. llvm-svn: 197497
2013-12-17 22:12:37 +08:00
TryConsumeToken(tok::equal);
C++1y n3648: parse and reject init-captures for now. llvm-svn: 181553
2013-05-10 05:36:41 +08:00
PR16094: I should have known Obj-C init-capture disambiguation couldn't be *that* easy... Try a bit harder to disambiguate. This is mostly straightforward, but for =-style initializers, we actually need to know where an expression ends: [foo = bar baz] is a message send, whereas [foo = bar + baz] is a lambda-introducer. Handle this by parsing the expression eagerly, and replacing it with an annotation token. By chance, we use the *exact same* parsing rules in both cases (except that we need to assume we're inside a message send for the parse, to turn off various forms of inapplicable error recovery). llvm-svn: 182432
2013-05-22 06:21:19 +08:00
if (!SkippedInits)
Init = ParseInitializer();
else if (Tok.is(tok::l_brace)) {
BalancedDelimiterTracker Braces(*this, tok::l_brace);
Braces.consumeOpen();
Braces.skipToEnd();
*SkippedInits = true;
} else {
// We're disambiguating this:
//
// [..., x = expr
//
// We need to find the end of the following expression in order to
PR19339: Disambiguate lambdas with init-captures from designated initializers properly. llvm-svn: 206128
2014-04-13 12:31:48 +08:00
// determine whether this is an Obj-C message send's receiver, a
// C99 designator, or a lambda init-capture.
PR16094: I should have known Obj-C init-capture disambiguation couldn't be *that* easy... Try a bit harder to disambiguate. This is mostly straightforward, but for =-style initializers, we actually need to know where an expression ends: [foo = bar baz] is a message send, whereas [foo = bar + baz] is a lambda-introducer. Handle this by parsing the expression eagerly, and replacing it with an annotation token. By chance, we use the *exact same* parsing rules in both cases (except that we need to assume we're inside a message send for the parse, to turn off various forms of inapplicable error recovery). llvm-svn: 182432
2013-05-22 06:21:19 +08:00
//
// Parse the expression to find where it ends, and annotate it back
// onto the tokens. We would have parsed this expression the same way
// in either case: both the RHS of an init-capture and the RHS of an
// assignment expression are parsed as an initializer-clause, and in
// neither case can anything be added to the scope between the '[' and
// here.
//
// FIXME: This is horrible. Adding a mechanism to skip an expression
// would be much cleaner.
// FIXME: If there is a ',' before the next ']' or ':', we can skip to
// that instead. (And if we see a ':' with no matching '?', we can
// classify this as an Obj-C message send.)
SourceLocation StartLoc = Tok.getLocation();
InMessageExpressionRAIIObject MaybeInMessageExpression(*this, true);
Init = ParseInitializer();
if (Tok.getLocation() != StartLoc) {
// Back out the lexing of the token after the initializer.
PP.RevertCachedTokens(1);
// Replace the consumed tokens with an appropriate annotation.
Tok.setLocation(StartLoc);
Tok.setKind(tok::annot_primary_expr);
setExprAnnotation(Tok, Init);
Tok.setAnnotationEndLoc(PP.getLastCachedTokenLocation());
PP.AnnotateCachedTokens(Tok);
// Consume the annotated initializer.
ConsumeToken();
}
}
Refactor and micro-optimize ConsumeToken() 1) Introduce TryConsumeToken() to handle the common test-and-consume pattern. This brings about readability improvements in the parser and optimizes to avoid redundant checks in the common case. 2) Eliminate the ConsumeCodeCompletionTok special case from ConsumeToken(). This was used by only one caller which has been switched over to the more appropriate ConsumeCodeCompletionToken() function. llvm-svn: 197497
2013-12-17 22:12:37 +08:00
} else
TryConsumeToken(tok::ellipsis, EllipsisLoc);
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
}
Fix init-captures for generic lambdas. For an init capture, process the initialization expression right away. For lambda init-captures such as the following: const int x = 10; auto L = [i = x+1](int a) { return [j = x+2, &k = x](char b) { }; }; keep in mind that each lambda init-capture has to have: - its initialization expression executed in the context of the enclosing/parent decl-context. - but the variable itself has to be 'injected' into the decl-context of its lambda's call-operator (which has not yet been created). Each init-expression is a full-expression that has to get Sema-analyzed (for capturing etc.) before its lambda's call-operator's decl-context, scope & scopeinfo are pushed on their respective stacks. Thus if any variable is odr-used in the init-capture it will correctly get captured in the enclosing lambda, if one exists. The init-variables above are created later once the lambdascope and call-operators decl-context is pushed onto its respective stack. Since the lambda init-capture's initializer expression occurs in the context of the enclosing function or lambda, therefore we can not wait till a lambda scope has been pushed on before deciding whether the variable needs to be captured. We also need to process all lvalue-to-rvalue conversions and discarded-value conversions, so that we can avoid capturing certain constant variables. For e.g., void test() { const int x = 10; auto L = [&z = x](char a) { <-- don't capture by the current lambda return [y = x](int i) { <-- don't capture by enclosing lambda return y; } }; If x was not const, the second use would require 'L' to capture, and that would be an error. Make sure TranformLambdaExpr is also aware of this. Patch approved by Richard (Thanks!!) http://llvm-reviews.chandlerc.com/D2092 llvm-svn: 196454
2013-12-05 09:40:41 +08:00
// If this is an init capture, process the initialization expression
// right away. For lambda init-captures such as the following:
// const int x = 10;
// auto L = [i = x+1](int a) {
// return [j = x+2,
// &k = x](char b) { };
// };
// keep in mind that each lambda init-capture has to have:
// - its initialization expression executed in the context
// of the enclosing/parent decl-context.
// - but the variable itself has to be 'injected' into the
// decl-context of its lambda's call-operator (which has
// not yet been created).
// Each init-expression is a full-expression that has to get
// Sema-analyzed (for capturing etc.) before its lambda's
// call-operator's decl-context, scope & scopeinfo are pushed on their
// respective stacks. Thus if any variable is odr-used in the init-capture
// it will correctly get captured in the enclosing lambda, if one exists.
// The init-variables above are created later once the lambdascope and
// call-operators decl-context is pushed onto its respective stack.
// Since the lambda init-capture's initializer expression occurs in the
// context of the enclosing function or lambda, therefore we can not wait
// till a lambda scope has been pushed on before deciding whether the
// variable needs to be captured. We also need to process all
// lvalue-to-rvalue conversions and discarded-value conversions,
// so that we can avoid capturing certain constant variables.
// For e.g.,
// void test() {
// const int x = 10;
// auto L = [&z = x](char a) { <-- don't capture by the current lambda
// return [y = x](int i) { <-- don't capture by enclosing lambda
// return y;
// }
// };
// If x was not const, the second use would require 'L' to capture, and
// that would be an error.
ParsedType InitCaptureParsedType;
if (Init.isUsable()) {
// Get the pointer and store it in an lvalue, so we can use it as an
// out argument.
Expr *InitExpr = Init.get();
// This performs any lvalue-to-rvalue conversions if necessary, which
// can affect what gets captured in the containing decl-context.
QualType InitCaptureType = Actions.performLambdaInitCaptureInitialization(
Loc, Kind == LCK_ByRef, Id, InitExpr);
Init = InitExpr;
InitCaptureParsedType.set(InitCaptureType);
}
Intro.addCapture(Kind, Loc, Id, EllipsisLoc, Init, InitCaptureParsedType);
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
}
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
Intro.Range.setEnd(T.getCloseLocation());
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
return DiagResult();
}
Implement code completion support for lambda capture lists. llvm-svn: 150583
2012-02-15 23:34:24 +08:00
/// TryParseLambdaIntroducer - Tentatively parse a lambda introducer.
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
///
/// Returns true if it hit something unexpected.
bool Parser::TryParseLambdaIntroducer(LambdaIntroducer &Intro) {
TentativeParsingAction PA(*this);
PR16094: I should have known Obj-C init-capture disambiguation couldn't be *that* easy... Try a bit harder to disambiguate. This is mostly straightforward, but for =-style initializers, we actually need to know where an expression ends: [foo = bar baz] is a message send, whereas [foo = bar + baz] is a lambda-introducer. Handle this by parsing the expression eagerly, and replacing it with an annotation token. By chance, we use the *exact same* parsing rules in both cases (except that we need to assume we're inside a message send for the parse, to turn off various forms of inapplicable error recovery). llvm-svn: 182432
2013-05-22 06:21:19 +08:00
bool SkippedInits = false;
Optional<unsigned> DiagID(ParseLambdaIntroducer(Intro, &SkippedInits));
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
if (DiagID) {
PA.Revert();
return true;
}
PR16094: I should have known Obj-C init-capture disambiguation couldn't be *that* easy... Try a bit harder to disambiguate. This is mostly straightforward, but for =-style initializers, we actually need to know where an expression ends: [foo = bar baz] is a message send, whereas [foo = bar + baz] is a lambda-introducer. Handle this by parsing the expression eagerly, and replacing it with an annotation token. By chance, we use the *exact same* parsing rules in both cases (except that we need to assume we're inside a message send for the parse, to turn off various forms of inapplicable error recovery). llvm-svn: 182432
2013-05-22 06:21:19 +08:00
if (SkippedInits) {
// Parse it again, but this time parse the init-captures too.
PA.Revert();
Intro = LambdaIntroducer();
DiagID = ParseLambdaIntroducer(Intro);
assert(!DiagID && "parsing lambda-introducer failed on reparse");
return false;
}
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
PA.Commit();
return false;
}
/// ParseLambdaExpressionAfterIntroducer - Parse the rest of a lambda
/// expression.
ExprResult Parser::ParseLambdaExpressionAfterIntroducer(
LambdaIntroducer &Intro) {
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
SourceLocation LambdaBeginLoc = Intro.Range.getBegin();
Diag(LambdaBeginLoc, diag::warn_cxx98_compat_lambda);
PrettyStackTraceLoc CrashInfo(PP.getSourceManager(), LambdaBeginLoc,
"lambda expression parsing");
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
C++1y n3648: parse and reject init-captures for now. llvm-svn: 181553
2013-05-10 05:36:41 +08:00
// FIXME: Call into Actions to add any init-capture declarations to the
// scope while parsing the lambda-declarator and compound-statement.
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
// Parse lambda-declarator[opt].
DeclSpec DS(AttrFactory);
Add an explicit LambdaExprContext to Declarator, to parallel BlockLiteralContext. Use it to ensure semantic analysis of types isn't confused by the lack of a type specifier. llvm-svn: 147522
2012-01-04 12:41:38 +08:00
Declarator D(DS, Declarator::LambdaExprContext);
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
TemplateParameterDepthRAII CurTemplateDepthTracker(TemplateParameterDepth);
Actions.PushLambdaScope();
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
if (Tok.is(tok::l_paren)) {
ParseScope PrototypeScope(this,
Scope::FunctionPrototypeScope |
Finish semantic analysis for [[carries_dependency]] attribute. This required plumbing through a new flag to determine whether a ParmVarDecl is actually a parameter of a function declaration (as opposed to a function typedef etc, where the attribute is prohibited). Weirdly, this attribute (just like [[noreturn]]) cannot be applied to a function type, just to a function declaration (and its parameters). llvm-svn: 173726
2013-01-29 06:42:45 +08:00
Scope::FunctionDeclarationScope |
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
Scope::DeclScope);
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
SourceLocation DeclEndLoc;
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren);
T.consumeOpen();
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
SourceLocation LParenLoc = T.getOpenLocation();
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
// Parse parameter-declaration-clause.
ParsedAttributes Attr(AttrFactory);
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallVector<DeclaratorChunk::ParamInfo, 16> ParamInfo;
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
SourceLocation EllipsisLoc;
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
if (Tok.isNot(tok::r_paren)) {
Actions.RecordParsingTemplateParameterDepth(TemplateParameterDepth);
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
ParseParameterDeclarationClause(D, Attr, ParamInfo, EllipsisLoc);
Implement a rudimentary form of generic lambdas. Specifically, the following features are not included in this commit: - any sort of capturing within generic lambdas - generic lambdas within template functions and nested within other generic lambdas - conversion operator for captureless lambdas - ensuring all visitors are generic lambda aware (Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit) As an example of what compiles through this commit: template <class F1, class F2> struct overload : F1, F2 { using F1::operator(); using F2::operator(); overload(F1 f1, F2 f2) : F1(f1), F2(f2) { } }; auto Recursive = [](auto Self, auto h, auto ... rest) { return 1 + Self(Self, rest...); }; auto Base = [](auto Self, auto h) { return 1; }; overload<decltype(Base), decltype(Recursive)> O(Base, Recursive); int num_params = O(O, 5, 3, "abc", 3.14, 'a'); Please see attached tests for more examples. This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics). Some implementation notes: - Add a new Declarator context => LambdaExprParameterContext to clang::Declarator to allow the use of 'auto' in declaring generic lambda parameters - Add various helpers to CXXRecordDecl to facilitate identifying and querying a closure class - LambdaScopeInfo (which maintains the current lambda's Sema state) was augmented to house the current depth of the template being parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth) so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately generate a template-parameter-type when 'auto' is parsed in a generic lambda parameter context. (i.e we do NOT use AutoType deduced to a template parameter type - Richard seemed ok with this approach). We encode that this template type was generated from an auto by simply adding $auto to the name which can be used for better diagnostics if needed. - SemaLambda.h was added to hold some common lambda utility functions (this file is likely to grow ...) - Teach Sema::ActOnStartOfFunctionDef to check whether it is being called to instantiate a generic lambda's call operator, and if so, push an appropriately prepared LambdaScopeInfo object on the stack. - various tests were added - but much more will be needed. There is obviously more work to be done, and both Richard (weakly) and Doug (strongly) have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData in a future patch which is forthcoming. A greatful thanks to all reviewers including Eli Friedman, James Dennett, and especially the two gracious wizards (Richard Smith and Doug Gregor) who spent hours providing feedback (in person in Chicago and on the mailing lists). And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified! Thanks! llvm-svn: 191453
2013-09-27 03:54:12 +08:00
// For a generic lambda, each 'auto' within the parameter declaration
// clause creates a template type parameter, so increment the depth.
if (Actions.getCurGenericLambda())
++CurTemplateDepthTracker;
}
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
SourceLocation RParenLoc = T.getCloseLocation();
DeclEndLoc = RParenLoc;
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
Allow GNU-style attributes on lambda expressions. llvm-svn: 203628
2014-03-12 08:01:07 +08:00
// GNU-style attributes must be parsed before the mutable specifier to be
// compatible with GCC.
MaybeParseGNUAttributes(Attr, &DeclEndLoc);
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
// Parse 'mutable'[opt].
SourceLocation MutableLoc;
Parse: Token consumption modernization and loop de-nesting Cleanup only. llvm-svn: 198539
2014-01-05 11:27:11 +08:00
if (TryConsumeToken(tok::kw_mutable, MutableLoc))
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
DeclEndLoc = MutableLoc;
// Parse exception-specification[opt].
ExceptionSpecificationType ESpecType = EST_None;
SourceRange ESpecRange;
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallVector<ParsedType, 2> DynamicExceptions;
SmallVector<SourceRange, 2> DynamicExceptionRanges;
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
ExprResult NoexceptExpr;
Revert most of r154844, which was disabled in r155975. Keep around the refactorings in that revision, and some of the subsequent bugfixes, which seem to be relevant even without delayed exception specification parsing. llvm-svn: 156031
2012-05-03 06:22:32 +08:00
ESpecType = tryParseExceptionSpecification(ESpecRange,
Implement the last part of C++ [class.mem]p2, delaying the parsing of exception specifications on member functions until after the closing '}' for the containing class. This allows, for example, a member function to throw an instance of its own class. Fixes PR12564 and a fairly embarassing oversight in our C++98/03 support. llvm-svn: 154844
2012-04-17 02:27:27 +08:00
DynamicExceptions,
DynamicExceptionRanges,
Revert most of r154844, which was disabled in r155975. Keep around the refactorings in that revision, and some of the subsequent bugfixes, which seem to be relevant even without delayed exception specification parsing. llvm-svn: 156031
2012-05-03 06:22:32 +08:00
NoexceptExpr);
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
if (ESpecType != EST_None)
DeclEndLoc = ESpecRange.getEnd();
// Parse attribute-specifier[opt].
s/CXX0X/CXX11/g, except for __GNU_EXPERIMENTAL_CXX0X__, and update a few nearby 'C++0x' comments. llvm-svn: 171372
2013-01-02 20:01:23 +08:00
MaybeParseCXX11Attributes(Attr, &DeclEndLoc);
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
SourceLocation FunLocalRangeEnd = DeclEndLoc;
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
// Parse trailing-return-type[opt].
If parsing a trailing-return-type fails, don't pretend we didn't have one at all. Suppresses follow-on errors mentioned in PR13074. llvm-svn: 158348
2012-06-12 09:51:59 +08:00
TypeResult TrailingReturnType;
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
if (Tok.is(tok::arrow)) {
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
FunLocalRangeEnd = Tok.getLocation();
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
SourceRange Range;
If parsing a trailing-return-type fails, don't pretend we didn't have one at all. Suppresses follow-on errors mentioned in PR13074. llvm-svn: 158348
2012-06-12 09:51:59 +08:00
TrailingReturnType = ParseTrailingReturnType(Range);
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
if (Range.getEnd().isValid())
DeclEndLoc = Range.getEnd();
}
PrototypeScope.Exit();
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
SourceLocation NoLoc;
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
D.AddTypeInfo(DeclaratorChunk::getFunction(/*hasProto=*/true,
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
/*isAmbiguous=*/false,
LParenLoc,
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
ParamInfo.data(), ParamInfo.size(),
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
EllipsisLoc, RParenLoc,
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
DS.getTypeQualifiers(),
/*RefQualifierIsLValueRef=*/true,
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
/*RefQualifierLoc=*/NoLoc,
/*ConstQualifierLoc=*/NoLoc,
/*VolatileQualifierLoc=*/NoLoc,
Add RestrictQualifierLoc to DeclaratorChunk::FunctionTypeInfo Clang supports __restrict__ as a function qualifier, but DeclaratorChunk::FunctionTypeInfo lacked a field to track the qualifier's source location (as we do with volatile, etc.). This was the subject of a FIXME in GetFullTypeForDeclarator (in SemaType.cpp). This should also prove useful as we add more warnings regarding questionable uses of the restrict qualifier. There is no significant functional change (except for an improved source range associated with the err_invalid_qualified_function_type diagnostic fixit generated by GetFullTypeForDeclarator). llvm-svn: 220215
2014-10-21 01:32:04 +08:00
/*RestrictQualifierLoc=*/NoLoc,
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
MutableLoc,
ESpecType, ESpecRange.getBegin(),
DynamicExceptions.data(),
DynamicExceptionRanges.data(),
DynamicExceptions.size(),
NoexceptExpr.isUsable() ?
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
NoexceptExpr.get() : nullptr,
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
LParenLoc, FunLocalRangeEnd, D,
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
TrailingReturnType),
Attr, DeclEndLoc);
Gracefully handle an attribute specifier following a lambda introducer when the parameter list wasn't present. llvm-svn: 203565
2014-03-11 21:03:15 +08:00
} else if (Tok.is(tok::kw_mutable) || Tok.is(tok::arrow) ||
Allow GNU-style attributes on lambda expressions. llvm-svn: 203628
2014-03-12 08:01:07 +08:00
Tok.is(tok::kw___attribute) ||
Gracefully handle an attribute specifier following a lambda introducer when the parameter list wasn't present. llvm-svn: 203565
2014-03-11 21:03:15 +08:00
(Tok.is(tok::l_square) && NextToken().is(tok::l_square))) {
// It's common to forget that one needs '()' before 'mutable', an attribute
// specifier, or the result type. Deal with this.
unsigned TokKind = 0;
switch (Tok.getKind()) {
case tok::kw_mutable: TokKind = 0; break;
case tok::arrow: TokKind = 1; break;
Allow GNU-style attributes on lambda expressions. llvm-svn: 203628
2014-03-12 08:01:07 +08:00
case tok::kw___attribute:
Gracefully handle an attribute specifier following a lambda introducer when the parameter list wasn't present. llvm-svn: 203565
2014-03-11 21:03:15 +08:00
case tok::l_square: TokKind = 2; break;
default: llvm_unreachable("Unknown token kind");
}
Improve recovery for lambda expressions that have 'mutable' or a trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. llvm-svn: 150727
2012-02-17 05:53:36 +08:00
Diag(Tok, diag::err_lambda_missing_parens)
Gracefully handle an attribute specifier following a lambda introducer when the parameter list wasn't present. llvm-svn: 203565
2014-03-11 21:03:15 +08:00
<< TokKind
Improve recovery for lambda expressions that have 'mutable' or a trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. llvm-svn: 150727
2012-02-17 05:53:36 +08:00
<< FixItHint::CreateInsertion(Tok.getLocation(), "() ");
SourceLocation DeclLoc = Tok.getLocation();
SourceLocation DeclEndLoc = DeclLoc;
Allow GNU-style attributes on lambda expressions. llvm-svn: 203628
2014-03-12 08:01:07 +08:00
// GNU-style attributes must be parsed before the mutable specifier to be
// compatible with GCC.
ParsedAttributes Attr(AttrFactory);
MaybeParseGNUAttributes(Attr, &DeclEndLoc);
Improve recovery for lambda expressions that have 'mutable' or a trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. llvm-svn: 150727
2012-02-17 05:53:36 +08:00
// Parse 'mutable', if it's there.
SourceLocation MutableLoc;
if (Tok.is(tok::kw_mutable)) {
MutableLoc = ConsumeToken();
DeclEndLoc = MutableLoc;
}
Gracefully handle an attribute specifier following a lambda introducer when the parameter list wasn't present. llvm-svn: 203565
2014-03-11 21:03:15 +08:00
// Parse attribute-specifier[opt].
MaybeParseCXX11Attributes(Attr, &DeclEndLoc);
Improve recovery for lambda expressions that have 'mutable' or a trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. llvm-svn: 150727
2012-02-17 05:53:36 +08:00
// Parse the return type, if there is one.
If parsing a trailing-return-type fails, don't pretend we didn't have one at all. Suppresses follow-on errors mentioned in PR13074. llvm-svn: 158348
2012-06-12 09:51:59 +08:00
TypeResult TrailingReturnType;
Improve recovery for lambda expressions that have 'mutable' or a trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. llvm-svn: 150727
2012-02-17 05:53:36 +08:00
if (Tok.is(tok::arrow)) {
SourceRange Range;
If parsing a trailing-return-type fails, don't pretend we didn't have one at all. Suppresses follow-on errors mentioned in PR13074. llvm-svn: 158348
2012-06-12 09:51:59 +08:00
TrailingReturnType = ParseTrailingReturnType(Range);
Improve recovery for lambda expressions that have 'mutable' or a trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. llvm-svn: 150727
2012-02-17 05:53:36 +08:00
if (Range.getEnd().isValid())
DeclEndLoc = Range.getEnd();
}
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
SourceLocation NoLoc;
Improve recovery for lambda expressions that have 'mutable' or a trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. llvm-svn: 150727
2012-02-17 05:53:36 +08:00
D.AddTypeInfo(DeclaratorChunk::getFunction(/*hasProto=*/true,
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
/*isAmbiguous=*/false,
/*LParenLoc=*/NoLoc,
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
/*Params=*/nullptr,
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
/*NumParams=*/0,
/*EllipsisLoc=*/NoLoc,
/*RParenLoc=*/NoLoc,
/*TypeQuals=*/0,
/*RefQualifierIsLValueRef=*/true,
/*RefQualifierLoc=*/NoLoc,
/*ConstQualifierLoc=*/NoLoc,
/*VolatileQualifierLoc=*/NoLoc,
Add RestrictQualifierLoc to DeclaratorChunk::FunctionTypeInfo Clang supports __restrict__ as a function qualifier, but DeclaratorChunk::FunctionTypeInfo lacked a field to track the qualifier's source location (as we do with volatile, etc.). This was the subject of a FIXME in GetFullTypeForDeclarator (in SemaType.cpp). This should also prove useful as we add more warnings regarding questionable uses of the restrict qualifier. There is no significant functional change (except for an improved source range associated with the err_invalid_qualified_function_type diagnostic fixit generated by GetFullTypeForDeclarator). llvm-svn: 220215
2014-10-21 01:32:04 +08:00
/*RestrictQualifierLoc=*/NoLoc,
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
MutableLoc,
EST_None,
/*ESpecLoc=*/NoLoc,
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
/*Exceptions=*/nullptr,
/*ExceptionRanges=*/nullptr,
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
/*NumExceptions=*/0,
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
/*NoexceptExpr=*/nullptr,
Fixed FunctionTypeLoc source range. llvm-svn: 165259
2012-10-05 05:42:10 +08:00
DeclLoc, DeclEndLoc, D,
TrailingReturnType),
Improve recovery for lambda expressions that have 'mutable' or a trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. llvm-svn: 150727
2012-02-17 05:53:36 +08:00
Attr, DeclEndLoc);
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
}
Improve recovery for lambda expressions that have 'mutable' or a trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. llvm-svn: 150727
2012-02-17 05:53:36 +08:00
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
More lambda work. Fixes a minor bug Richard pointed out, makes lookup for lambda parameters work correctly, recording more information into the AST. llvm-svn: 147650
2012-01-06 11:05:34 +08:00
// FIXME: Rename BlockScope -> ClosureScope if we decide to continue using
// it.
In the conflict between C++11 [expr.prim.general]p4, which declares that 'this' can be used in the brace-or-equal-initializer of a non-static data member, and C++11 [expr.prim.lambda]p9, which says that lambda expressions not in block scope can have no captures, side fully with C++11 [expr.prim.general]p4 by allowing 'this' to be captured within these initializers. This seems to be the intent of non-static data member initializers. llvm-svn: 151101
2012-02-22 06:51:27 +08:00
unsigned ScopeFlags = Scope::BlockScope | Scope::FnScope | Scope::DeclScope;
ParseScope BodyScope(this, ScopeFlags);
More lambda work. Fixes a minor bug Richard pointed out, makes lookup for lambda parameters work correctly, recording more information into the AST. llvm-svn: 147650
2012-01-06 11:05:34 +08:00
More lambda work. Tweak the Sema interface slightly. Start adding the pieces to build the lambda class and its call operator. Create an actual scope for the lambda body. llvm-svn: 147595
2012-01-05 11:35:19 +08:00
Actions.ActOnStartOfLambdaDefinition(Intro, D, getCurScope());
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
// Parse compound-statement.
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
if (!Tok.is(tok::l_brace)) {
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
Diag(Tok, diag::err_expected_lambda_body);
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
Actions.ActOnLambdaError(LambdaBeginLoc, getCurScope());
return ExprError();
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +08:00
}
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
StmtResult Stmt(ParseCompoundStatementBody());
BodyScope.Exit();
Fix messed-up indentation in r147515. llvm-svn: 147517
2012-01-04 10:46:53 +08:00
if (!Stmt.isInvalid())
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
return Actions.ActOnLambdaExpr(LambdaBeginLoc, Stmt.get(), getCurScope());
Stub out the Sema interface for lambda expressions, and change the parser to use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet. llvm-svn: 147515
2012-01-04 10:40:39 +08:00
Fix messed-up indentation in r147515. llvm-svn: 147517
2012-01-04 10:46:53 +08:00
Actions.ActOnLambdaError(LambdaBeginLoc, getCurScope());
return ExprError();
Parsing of C++0x lambda expressions, from John Freeman with help from David Blaikie! llvm-svn: 136876
2011-08-04 23:30:47 +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();
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
const char *CastName = nullptr; // For error messages
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
switch (Kind) {
Removing a bunch of dead returns/breaks after llvm_unreachables. llvm-svn: 140407
2011-09-24 04:26:49 +08:00
default: llvm_unreachable("Unknown C++ cast!");
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
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();
Detect when the string "<::" is found in code after a cast or template name and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::". Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro. llvm-svn: 129540
2011-04-15 05:45:45 +08:00
// Check for "<::" which is parsed as "[:". If found, fix token stream,
// diagnose error, suggest fix, and recover parsing.
PR13619: Make sure we're not at EOF before looking at NextToken(). llvm-svn: 162212
2012-08-21 01:37:52 +08:00
if (Tok.is(tok::l_square) && Tok.getLength() == 2) {
Token Next = NextToken();
if (Next.is(tok::colon) && areTokensAdjacent(Tok, Next))
FixDigraph(*this, PP, Tok, Next, Kind, /*AtDigraph*/true);
}
Detect when the string "<::" is found in code after a cast or template name and is interpreted as "[:" because of the digraph "<:". When found, give an error with a fix-it to add whitespace between the "<" and "::". Patch by Richard Trieu! Plus a small tweak from me to deal with one of the tokens coming from a macro. llvm-svn: 129540
2011-04-15 05:45:45 +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
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
[ARC] When casting from a pointer to an objective-c object with known ownership, if the cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type to the cast type: id x; static_cast<NSString**>(&x); // Casting as (__strong NSString**). This currently only works for C++ named casts, C casts to follow. llvm-svn: 134273
2011-07-02 06:22:50 +08:00
// Parse the common declaration-specifiers piece.
DeclSpec DS(AttrFactory);
ParseSpecifierQualifierList(DS);
// Parse the abstract-declarator, if present.
Declarator DeclaratorInfo(DS, Declarator::TypeNameContext);
ParseDeclarator(DeclaratorInfo);
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();
ExpectAndConsume: Diagnose errors automatically 1) Teach ExpectAndConsume() to emit expected and expected-after diagnostics using the generic diagnostic descriptions added in r197972, eliminating another set of trivial err_expected_* variations while maintaining existing behaviour. 2) Lift SkipUntil() recovery out of ExpectAndConsume(). The Expect/Consume family of functions are primitive parser operations that now have the well-defined property of operating on single tokens. Factoring out recovery exposes opportunities for more consistent and tailored error recover at the call sites instead of just relying on a bottled SkipUntil formula. llvm-svn: 198270
2014-01-01 11:08:43 +08:00
if (ExpectAndConsume(tok::greater))
Support and use token kinds as diagnostic arguments Introduce proper facilities to render token spellings using the diagnostic formatter. Replaces most of the hard-coded diagnostic messages related to expected tokens, which all shared the same semantics but had to be multiply defined due to variations in token order or quote marks. The associated parser changes are largely mechanical but they expose commonality in whole chunks of the parser that can now be factored away. This commit uses C++11 typed enums along with a speculative legacy fallback until the transition is complete. Requires corresponding changes in LLVM r197895. llvm-svn: 197972
2013-12-24 17:48:30 +08:00
return ExprError(Diag(LAngleBracketLoc, diag::note_matching) << tok::less);
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
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
SourceLocation LParenLoc, RParenLoc;
BalancedDelimiterTracker T(*this, tok::l_paren);
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
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
if (T.expectAndConsume(diag::err_expected_lparen_after, CastName))
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
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 ')'.
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
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
[ARC] When casting from a pointer to an objective-c object with known ownership, if the cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type to the cast type: id x; static_cast<NSString**>(&x); // Casting as (__strong NSString**). This currently only works for C++ named casts, C casts to follow. llvm-svn: 134273
2011-07-02 06:22:50 +08:00
if (!Result.isInvalid() && !DeclaratorInfo.isInvalidType())
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,
[ARC] When casting from a pointer to an objective-c object with known ownership, if the cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type to the cast type: id x; static_cast<NSString**>(&x); // Casting as (__strong NSString**). This currently only works for C++ named casts, C casts to follow. llvm-svn: 134273
2011-07-02 06:22:50 +08:00
LAngleBracketLoc, DeclaratorInfo,
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,
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
T.getOpenLocation(), Result.get(),
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.getCloseLocation());
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
Rip out remnants of move semantic emulation and smart pointers in Sema. These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
2012-08-24 05:35:17 +08:00
return 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();
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
SourceLocation LParenLoc, RParenLoc;
BalancedDelimiterTracker T(*this, tok::l_paren);
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
// typeid expressions are always parenthesized.
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
if (T.expectAndConsume(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();
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
LParenLoc = T.getOpenLocation();
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
PR41111, PR5925, PR13210: Teach tentative parsing to annotate identifiers and nested names as id-expressions, using the annot_primary_expr annotation, where possible. This removes some redundant lookups, and also allows us to typo-correct within tentative parsing, and to carry on disambiguating past an identifier which we can determine will fail lookup as both a type and as a non-type, allowing us to disambiguate more declarations (and thus offer improved error recovery for such cases). This also introduces to the parser the notion of a tentatively-declared name, which is an identifier which we *might* have seen a declaration for in a tentative parse (but only if we end up disambiguating the tokens as a declaration). This is necessary to correctly disambiguate cases where a variable is used within its own initializer. llvm-svn: 162159
2012-08-18 08:55:03 +08:00
// C++0x [expr.typeid]p3:
// When typeid is applied to an expression other than an lvalue of a
// polymorphic class type [...] The expression is an unevaluated
// operand (Clause 5).
//
// Note that we can't tell whether the expression is an lvalue of a
// polymorphic class type until after we've parsed the expression; we
// speculatively assume the subexpression is unevaluated, and fix it up
// later.
//
// We enter the unevaluated context before trying to determine whether we
// have a type-id, because the tentative parse logic will try to resolve
// names, and must treat them as unevaluated.
Fix an edge case of mangling involving the combination of a lambda and typeid. typeid (and a couple other non-standard places where we can transform an unevaluated expression into an evaluated expression) is special because it introduces an an expression evaluation context, which conflicts with the mechanism to compute the current lambda mangling context. PR12123. I would appreciate if someone would double-check that we get the mangling correct with this patch. llvm-svn: 164658
2012-09-26 12:34:21 +08:00
EnterExpressionEvaluationContext Unevaluated(Actions, Sema::Unevaluated,
Sema::ReuseLambdaContextDecl);
PR41111, PR5925, PR13210: Teach tentative parsing to annotate identifiers and nested names as id-expressions, using the annot_primary_expr annotation, where possible. This removes some redundant lookups, and also allows us to typo-correct within tentative parsing, and to carry on disambiguating past an identifier which we can determine will fail lookup as both a type and as a non-type, allowing us to disambiguate more declarations (and thus offer improved error recovery for such cases). This also introduces to the parser the notion of a tentatively-declared name, which is an identifier which we *might* have seen a declaration for in a tentative parse (but only if we end up disambiguating the tokens as a declaration). This is necessary to correctly disambiguate cases where a variable is used within its own initializer. llvm-svn: 162159
2012-08-18 08:55:03 +08:00
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 ')'.
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
RParenLoc = T.getCloseLocation();
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 {
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())
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::r_paren, StopAtSemi);
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
else {
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
RParenLoc = T.getCloseLocation();
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 (RParenLoc.isInvalid())
return ExprError();
Fixes for some more expressions containing function templateids that should be resolvable, from Faisal Vali! llvm-svn: 127521
2011-03-12 09:48:56 +08:00
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
Result = Actions.ActOnCXXTypeid(OpLoc, LParenLoc, /*isType=*/false,
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Result.get(), RParenLoc);
Implement C++ 'typeid' parsing and sema. llvm-svn: 59042
2008-11-11 19:37:55 +08:00
}
}
Rip out remnants of move semantic emulation and smart pointers in Sema. These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
2012-08-24 05:35:17 +08:00
return 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();
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren);
Microsoft's __uuidof operator implementation part 1. llvm-svn: 113356
2010-09-08 20:20:18 +08:00
// __uuidof expressions are always parenthesized.
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
if (T.expectAndConsume(diag::err_expected_lparen_after, "__uuidof"))
Microsoft's __uuidof operator implementation part 1. llvm-svn: 113356
2010-09-08 20:20:18 +08:00
return ExprError();
ExprResult Result;
if (isTypeIdInParens()) {
TypeResult Ty = ParseTypeName();
// Match the ')'.
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
Microsoft's __uuidof operator implementation part 1. llvm-svn: 113356
2010-09-08 20:20:18 +08:00
if (Ty.isInvalid())
return ExprError();
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
Result = Actions.ActOnCXXUuidof(OpLoc, T.getOpenLocation(), /*isType=*/true,
Ty.get().getAsOpaquePtr(),
T.getCloseLocation());
Microsoft's __uuidof operator implementation part 1. llvm-svn: 113356
2010-09-08 20:20:18 +08:00
} else {
EnterExpressionEvaluationContext Unevaluated(Actions, Sema::Unevaluated);
Result = ParseExpression();
// Match the ')'.
if (Result.isInvalid())
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::r_paren, StopAtSemi);
Microsoft's __uuidof operator implementation part 1. llvm-svn: 113356
2010-09-08 20:20:18 +08:00
else {
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
Microsoft's __uuidof operator implementation part 1. llvm-svn: 113356
2010-09-08 20:20:18 +08:00
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
Result = Actions.ActOnCXXUuidof(OpLoc, T.getOpenLocation(),
/*isType=*/false,
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Result.get(), T.getCloseLocation());
Microsoft's __uuidof operator implementation part 1. llvm-svn: 113356
2010-09-08 20:20:18 +08:00
}
}
Rip out remnants of move semantic emulation and smart pointers in Sema. These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
2012-08-24 05:35:17 +08:00
return Result;
Microsoft's __uuidof operator implementation part 1. llvm-svn: 113356
2010-09-08 20:20:18 +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
/// \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
Remove the last couple uses of the ExprArg(just Expr*) typedef in Parser. llvm-svn: 220897
2014-10-30 13:30:05 +08:00
Parser::ParseCXXPseudoDestructor(Expr *Base, SourceLocation OpLoc,
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
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)) {
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
// FIXME: retrieve TemplateKWLoc from template-id annotation and
// store it in the pseudo-dtor node (to be used when instantiating 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
FirstTypeName.setTemplateId(
(TemplateIdAnnotation *)Tok.getAnnotationValue());
ConsumeToken();
assert(Tok.is(tok::coloncolon) &&"ParseOptionalCXXScopeSpecifier fail");
CCLoc = ConsumeToken();
} else {
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
FirstTypeName.setIdentifier(nullptr, 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
}
// Parse the tilde.
assert(Tok.is(tok::tilde) && "ParseOptionalCXXScopeSpecifier fail");
SourceLocation TildeLoc = ConsumeToken();
Support decltype in pseudo destructors and dependent destructor calls. Reviewed by Eli Friedman. llvm-svn: 146738
2011-12-17 00:03:09 +08:00
if (Tok.is(tok::kw_decltype) && !FirstTypeName.isValid() && SS.isEmpty()) {
DeclSpec DS(AttrFactory);
Silence gcc warnings. llvm-svn: 146847
2011-12-18 20:18:02 +08:00
ParseDecltypeSpecifier(DS);
Support decltype in pseudo destructors and dependent destructor calls. Reviewed by Eli Friedman. llvm-svn: 146738
2011-12-17 00:03:09 +08:00
if (DS.getTypeSpecType() == TST_error)
return ExprError();
return Actions.ActOnPseudoDestructorExpr(getCurScope(), Base, OpLoc,
OpKind, TildeLoc, DS,
Tok.is(tok::l_paren));
}
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 (!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) &&
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
ParseUnqualifiedIdTemplateId(SS, SourceLocation(),
Name, NameLoc,
false, ObjectType, SecondTypeName,
/*AssumeTemplateName=*/true))
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:
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
return Actions.ActOnCXXThrow(getCurScope(), ThrowLoc, nullptr);
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());
Rip out remnants of move semantic emulation and smart pointers in Sema. These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
2012-08-24 05:35:17 +08:00
if (Expr.isInvalid()) return Expr;
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
return Actions.ActOnCXXThrow(getCurScope(), ThrowLoc, Expr.get());
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()").
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
/// See [C++ 5.2.3].
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
///
/// postfix-expression: [C++ 5.2p1]
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
/// simple-type-specifier '(' expression-list[opt] ')'
/// [C++0x] simple-type-specifier braced-init-list
/// typename-specifier '(' expression-list[opt] ')'
/// [C++0x] typename-specifier braced-init-list
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
///
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
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
assert((Tok.is(tok::l_paren) ||
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
(getLangOpts().CPlusPlus11 && Tok.is(tok::l_brace)))
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
&& "Expected '(' or '{'!");
When we're inside a functional cast, '>' is an operator. Fixes PR8912. llvm-svn: 123201
2011-01-11 08:33:19 +08:00
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
if (Tok.is(tok::l_brace)) {
Proper initializer list support for new expressions and type construct expressions. Array new still missing. llvm-svn: 150346
2012-02-13 02:41:05 +08:00
ExprResult Init = ParseBraceInitializer();
if (Init.isInvalid())
return Init;
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Expr *InitList = Init.get();
Proper initializer list support for new expressions and type construct expressions. Array new still missing. llvm-svn: 150346
2012-02-13 02:41:05 +08:00
return Actions.ActOnCXXTypeConstructExpr(TypeRep, SourceLocation(),
MultiExprArg(&InitList, 1),
SourceLocation());
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
} else {
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren);
T.consumeOpen();
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
Remove ASTOwningVector, it doesn't own anything and provides no value over SmallVector. llvm-svn: 162492
2012-08-24 06:51:59 +08:00
ExprVector Exprs;
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
CommaLocsTy CommaLocs;
if (Tok.isNot(tok::r_paren)) {
if (ParseExpressionList(Exprs, CommaLocs)) {
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::r_paren, StopAtSemi);
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +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
}
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
// Match the ')'.
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
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
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
// TypeRep could be null, if it references an invalid typedef.
if (!TypeRep)
return ExprError();
Make functional-style casts emit correct messages, and fix a crash-on-invalid. llvm-svn: 77451
2009-07-29 21:50:23 +08:00
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
assert((Exprs.size() == 0 || Exprs.size()-1 == CommaLocs.size())&&
"Unexpected number of commas!");
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
return Actions.ActOnCXXTypeConstructExpr(TypeRep, T.getOpenLocation(),
Rip out remnants of move semantic emulation and smart pointers in Sema. These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
2012-08-24 05:35:17 +08:00
Exprs,
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.getCloseLocation());
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23: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
}
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
Accept braced-init-lists in conditions, and, in passing, dramatically improve the diagnostic for using a parenthesized direct-initializer in a condition. llvm-svn: 151137
2012-02-22 14:49:09 +08:00
/// [C++11] type-specifier-seq declarator '=' initializer-clause
/// [C++11] type-specifier-seq declarator braced-init-list
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
/// [GNU] type-specifier-seq declarator simple-asm-expr[opt] attributes[opt]
/// '=' assignment-expression
///
Fix a few -Wdocumentation warnings. llvm-svn: 162506
2012-08-24 08:01:24 +08:00
/// \param ExprOut if the condition was parsed as an expression, the parsed
/// 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
///
Fix a few -Wdocumentation warnings. llvm-svn: 162506
2012-08-24 08:01:24 +08:00
/// \param DeclOut if the condition was parsed as a declaration, the parsed
/// declaration.
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
///
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);
Support code-completion for C++ inline methods and ObjC buffering methods. Previously we would cut off the source file buffer at the code-completion point; this impeded code-completion inside C++ inline methods and, recently, with buffering ObjC methods. Have the code-completion inserted into the source buffer so that it can be buffered along with a method body. When we actually hit the code-completion point the cut-off lexing or parsing. Fixes rdar://10056932&8319466 llvm-svn: 139086
2011-09-04 11:32:15 +08:00
cutOffParsing();
return true;
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
}
Clean up a large number of C++11 attribute parse issues, including parsing attributes in more places where we didn't and catching a lot more issues. This implements nearly every aspect of C++11 attribute parsing, except for: - Attributes are permitted on explicit instantiations inside the declarator (but not preceding the decl-spec) - Attributes are permitted on friend declarations of functions. - Multiple instances of the same attribute in an attribute-list (e.g. [[noreturn, noreturn]], not [[noreturn]] [[noreturn]] which is conforming) are allowed. The first two are marked as expected-FIXME in the test file and the latter is probably a defect and is currently untested. Thanks to Richard Smith for providing the lion's share of the testcases. llvm-svn: 159072
2012-06-23 13:07:58 +08:00
ParsedAttributesWithRange attrs(AttrFactory);
s/CXX0X/CXX11/g, except for __GNU_EXPERIMENTAL_CXX0X__, and update a few nearby 'C++0x' comments. llvm-svn: 171372
2013-01-02 20:01:23 +08:00
MaybeParseCXX11Attributes(attrs);
Clean up a large number of C++11 attribute parse issues, including parsing attributes in more places where we didn't and catching a lot more issues. This implements nearly every aspect of C++11 attribute parsing, except for: - Attributes are permitted on explicit instantiations inside the declarator (but not preceding the decl-spec) - Attributes are permitted on friend declarations of functions. - Multiple instances of the same attribute in an attribute-list (e.g. [[noreturn, noreturn]], not [[noreturn]] [[noreturn]] which is conforming) are allowed. The first two are marked as expected-FIXME in the test file and the latter is probably a defect and is currently untested. Thanks to Richard Smith for providing the lion's share of the testcases. llvm-svn: 159072
2012-06-23 13:07:58 +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()) {
Clean up a large number of C++11 attribute parse issues, including parsing attributes in more places where we didn't and catching a lot more issues. This implements nearly every aspect of C++11 attribute parsing, except for: - Attributes are permitted on explicit instantiations inside the declarator (but not preceding the decl-spec) - Attributes are permitted on friend declarations of functions. - Multiple instances of the same attribute in an attribute-list (e.g. [[noreturn, noreturn]], not [[noreturn]] [[noreturn]] which is conforming) are allowed. The first two are marked as expected-FIXME in the test file and the latter is probably a defect and is currently untested. Thanks to Richard Smith for providing the lion's share of the testcases. llvm-svn: 159072
2012-06-23 13:07:58 +08:00
ProhibitAttributes(attrs);
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
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
DeclOut = nullptr;
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
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
Insomniac refactoring: change how the parser allocates attributes so that AttributeLists do not accumulate over the lifetime of parsing, but are instead reused. Also make the arguments array not require a separate allocation, and make availability attributes store their stuff in augmented memory, too. llvm-svn: 128209
2011-03-24 19:26:52 +08:00
DeclSpec DS(AttrFactory);
Process and handle attributes on conditions and for loop variables. Process and diagnose attributes on alias declarations, using directives, and attribute declarations. llvm-svn: 175649
2013-02-21 03:22:51 +08:00
DS.takeAttributesFrom(attrs);
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
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()) {
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::semi, StopAtSemi);
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
}
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
DeclaratorInfo.setAsmLabel(AsmLabel.get());
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.
Refactor how we collect attributes during parsing, and add slots for attributes on array and function declarators. This is pretty far from complete, and I'll revisit it later if someone doesn't beat me to it. llvm-svn: 122535
2010-12-24 10:08:15 +08:00
MaybeParseGNUAttributes(DeclaratorInfo);
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(),
Refactor how we collect attributes during parsing, and add slots for attributes on array and function declarators. This is pretty far from complete, and I'll revisit it later if someone doesn't beat me to it. llvm-svn: 122535
2010-12-24 10:08:15 +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();
When we encounter a '==' in a context expecting a '=', assume the user made a typo: t.c:1:7: error: invalid '==' at end of declaration; did you mean '='? int x == 0; ^~ = Implements rdar://8488464. llvm-svn: 116035
2010-10-08 10:39:23 +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
Change the error when a '+=' follows a declaration to suggest a fixit to '=' instead of just suggesting a ';'. Old error: plusequaldeclare1.cc:3:8: error: expected ';' at end of declaration int x += 6; ^ ; New error: plusequaldeclare1.cc:3:9: error: invalid '+=' at end of declaration; did you mean '='? int x += 6; ^~ = llvm-svn: 148433
2012-01-19 06:54:52 +08:00
// If a '==' or '+=' is found, suggest a fixit to '='.
Accept braced-init-lists in conditions, and, in passing, dramatically improve the diagnostic for using a parenthesized direct-initializer in a condition. llvm-svn: 151137
2012-02-22 14:49:09 +08:00
bool CopyInitialization = isTokenEqualOrEqualTypo();
if (CopyInitialization)
Fix warnings found by gcc-4.6, from -Wunused-but-set-variable and -Wint-to-pointer-cast. llvm-svn: 123719
2011-01-18 10:00:16 +08:00
ConsumeToken();
Accept braced-init-lists in conditions, and, in passing, dramatically improve the diagnostic for using a parenthesized direct-initializer in a condition. llvm-svn: 151137
2012-02-22 14:49:09 +08:00
ExprResult InitExpr = ExprError();
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
if (getLangOpts().CPlusPlus11 && Tok.is(tok::l_brace)) {
Accept braced-init-lists in conditions, and, in passing, dramatically improve the diagnostic for using a parenthesized direct-initializer in a condition. llvm-svn: 151137
2012-02-22 14:49:09 +08:00
Diag(Tok.getLocation(),
diag::warn_cxx98_compat_generalized_initializer_lists);
InitExpr = ParseBraceInitializer();
} else if (CopyInitialization) {
InitExpr = ParseAssignmentExpression();
} else if (Tok.is(tok::l_paren)) {
// This was probably an attempt to initialize the variable.
SourceLocation LParen = ConsumeParen(), RParen = LParen;
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
if (SkipUntil(tok::r_paren, StopAtSemi | StopBeforeMatch))
Accept braced-init-lists in conditions, and, in passing, dramatically improve the diagnostic for using a parenthesized direct-initializer in a condition. llvm-svn: 151137
2012-02-22 14:49:09 +08:00
RParen = ConsumeParen();
Diag(DeclOut ? DeclOut->getLocation() : LParen,
diag::err_expected_init_in_condition_lparen)
<< SourceRange(LParen, RParen);
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 {
Accept braced-init-lists in conditions, and, in passing, dramatically improve the diagnostic for using a parenthesized direct-initializer in a condition. llvm-svn: 151137
2012-02-22 14:49:09 +08:00
Diag(DeclOut ? DeclOut->getLocation() : Tok.getLocation(),
diag::err_expected_init_in_condition);
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
}
Accept braced-init-lists in conditions, and, in passing, dramatically improve the diagnostic for using a parenthesized direct-initializer in a condition. llvm-svn: 151137
2012-02-22 14:49:09 +08:00
if (!InitExpr.isInvalid())
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Actions.AddInitializerToDecl(DeclOut, InitExpr.get(), !CopyInitialization,
Implement C++1y decltype(auto). llvm-svn: 180610
2013-04-27 00:15:35 +08:00
DS.containsPlaceholderType());
Don't treat a non-deduced 'auto' type as being type-dependent. Instead, there are now two distinct canonical 'AutoType's: one is the undeduced 'auto' placeholder type, and the other is a deduced-but-dependent type. All deduced-to-a-non-dependent-type cases are still non-canonical. llvm-svn: 180789
2013-04-30 21:56:41 +08:00
else
Actions.ActOnInitializerError(DeclOut);
Accept braced-init-lists in conditions, and, in passing, dramatically improve the diagnostic for using a parenthesized direct-initializer in a condition. llvm-svn: 151137
2012-02-22 14:49:09 +08:00
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).
Tweaks to C++0x deduced auto type support: * Flag indicating 'we're parsing this auto typed variable's initializer' moved from VarDecl to Sema * Temporary template parameter list for auto deduction is now allocated on the stack. * Deduced 'auto' types are now uniqued. llvm-svn: 126139
2011-02-22 04:05:19 +08:00
Actions.FinalizeDeclaration(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
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
}
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();
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
const clang::PrintingPolicy &Policy =
Actions.getASTContext().getPrintingPolicy();
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
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Annotation token should already be formed!");
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
default:
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
llvm_unreachable("Not a simple-type-specifier token!");
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: {
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
if (getTypeAnnotation(Tok))
DS.SetTypeSpecType(DeclSpec::TST_typename, Loc, PrevSpec, DiagID,
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
getTypeAnnotation(Tok), Policy);
Implement support for non-type template parameter packs whose type is a pack expansion, e.g., the parameter pack Values in: template<typename ...Types> struct Outer { template<Types ...Values> struct Inner; }; This new implementation approach introduces the notion of an "expanded" non-type template parameter pack, for which we have already expanded the types of the parameter pack (to, say, "int*, float*", for Outer<int*, float*>) but have not yet expanded the values. Aside from creating these expanded non-type template parameter packs, this patch updates template argument checking and non-type template parameter pack instantiation to make use of the appropriate types in the parameter pack. llvm-svn: 123845
2011-01-20 04:10:05 +08:00
else
DS.SetTypeSpecError();
Teach the C++ simple-type-specifier parser and tentative parses about protocol-qualified types such as id<Protocol>. llvm-svn: 117081
2010-10-22 07:17:00 +08:00
DS.SetRangeEnd(Tok.getAnnotationEndLoc());
ConsumeToken();
// Objective-C supports syntax of the form 'id<proto1,proto2>' where 'id'
// is a specific typedef and 'itf<proto1,proto2>' where 'itf' is an
// Objective-C interface. If we don't have Objective-C or a '<', this is
// just a normal reference to a typedef name.
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (Tok.is(tok::less) && getLangOpts().ObjC1)
Teach the C++ simple-type-specifier parser and tentative parses about protocol-qualified types such as id<Protocol>. llvm-svn: 117081
2010-10-22 07:17:00 +08:00
ParseObjCProtocolQualifiers(DS);
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.Finish(Diags, PP, Policy);
Teach the C++ simple-type-specifier parser and tentative parses about protocol-qualified types such as id<Protocol>. llvm-svn: 117081
2010-10-22 07:17:00 +08:00
return;
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
}
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:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecWidth(DeclSpec::TSW_short, Loc, PrevSpec, DiagID, Policy);
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:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecWidth(DeclSpec::TSW_long, Loc, PrevSpec, DiagID, Policy);
Upgrade Microsoft's __int8, __int16, __int32 and __int64 types from builtin defines to real types. Otherwise statements like: __int64 var = __int64(0); would be expanded to: long long var = long long(0); and fail to compile. llvm-svn: 130369
2011-04-28 09:59:37 +08:00
break;
case tok::kw___int64:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecWidth(DeclSpec::TSW_longlong, Loc, PrevSpec, DiagID, Policy);
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:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_void, Loc, PrevSpec, DiagID, Policy);
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:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_char, Loc, PrevSpec, DiagID, Policy);
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:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_int, Loc, PrevSpec, DiagID, Policy);
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;
For PR11916: Add support for g++'s __int128 keyword. Unlike __int128_t, this is a type specifier and can be combined with unsigned. This allows libstdc++4.7 to be used with clang in c++98 mode. Several other changes are still required for libstdc++4.7 to work with clang in c++11 mode. llvm-svn: 153999
2012-04-04 14:24:32 +08:00
case tok::kw___int128:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_int128, Loc, PrevSpec, DiagID, Policy);
For PR11916: Add support for g++'s __int128 keyword. Unlike __int128_t, this is a type specifier and can be combined with unsigned. This allows libstdc++4.7 to be used with clang in c++98 mode. Several other changes are still required for libstdc++4.7 to work with clang in c++11 mode. llvm-svn: 153999
2012-04-04 14:24:32 +08:00
break;
Provide half floating point support as a storage only type. Lack of half FP was a regression compared to llvm-gcc. llvm-svn: 142016
2011-10-15 07:23:15 +08:00
case tok::kw_half:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_half, Loc, PrevSpec, DiagID, Policy);
Provide half floating point support as a storage only type. Lack of half FP was a regression compared to llvm-gcc. llvm-svn: 142016
2011-10-15 07:23:15 +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_float:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_float, Loc, PrevSpec, DiagID, Policy);
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:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_double, Loc, PrevSpec, DiagID, Policy);
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:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_wchar, Loc, PrevSpec, DiagID, Policy);
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:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_char16, Loc, PrevSpec, DiagID, Policy);
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:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_char32, Loc, PrevSpec, DiagID, Policy);
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:
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.SetTypeSpecType(DeclSpec::TST_bool, Loc, PrevSpec, DiagID, Policy);
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;
Support decltype as a simple-type-specifier. This makes all sorts of fun examples work with decltype. Reviewed by Richard Smith. llvm-svn: 148787
2012-01-24 13:47:35 +08:00
case tok::annot_decltype:
case tok::kw_decltype:
DS.SetRangeEnd(ParseDecltypeSpecifier(DS));
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
return DS.Finish(Diags, PP, Policy);
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
// GNU typeof support.
case tok::kw_typeof:
ParseTypeofSpecifier(DS);
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.Finish(Diags, PP, Policy);
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();
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.Finish(Diags, PP, Policy);
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) {
Fix parsing of type-specifier-seq's. Types are syntactically allowed to be defined here, but not semantically, so new struct S {}; is always ill-formed, even if there is a struct S in scope. We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being under-loved (due to it only being used in a few places) so merge it into ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this required improving ParseDeclarationSpecifiers' diagnostics in some cases. This also required teaching ParseSpecifierQualifierList about constexpr... which incidentally fixes an issue where we'd allow the constexpr specifier in other bad places. llvm-svn: 152549
2012-03-12 15:56:15 +08:00
ParseSpecifierQualifierList(DS, AS_none, DSC_type_specifier);
Fix for PR9812: warn about bool instead of _Bool. llvm-svn: 199311
2014-01-15 17:15:43 +08:00
DS.Finish(Diags, PP, Actions.getASTContext().getPrintingPolicy());
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,
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
SourceLocation 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
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,
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
bool AssumeTemplateId) {
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
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) {
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
TNK = Actions.ActOnDependentTemplateName(getCurScope(), SS, 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
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 ");
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
TNK = Actions.ActOnDependentTemplateName(getCurScope(),
SS, TemplateKWLoc, Id,
ObjectType, EnteringContext,
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 (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) {
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
TNK = Actions.ActOnDependentTemplateName(getCurScope(),
SS, TemplateKWLoc, TemplateName,
ObjectType, EnteringContext,
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 (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,
Push nested-name-specifier source-location information into dependent template specialization types. This also required some parser tweaks, since we were losing track of the nested-name-specifier's source location information in several places in the parser. Other notable changes this required: - Sema::ActOnTagTemplateIdType now type-checks and forms the appropriate type nodes (+ source-location information) for an elaborated-type-specifier ending in a template-id. Previously, we used a combination of ActOnTemplateIdType and ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped around a DependentTemplateSpecializationType, which duplicated the keyword ("class", "struct", etc.) and nested-name-specifier storage. - Sema::ActOnTemplateIdType now gets a nested-name-specifier, which it places into the returned type-source location information. - Sema::ActOnDependentTag now creates types with source-location information. llvm-svn: 126808
2011-03-02 08:47:37 +08:00
SS, true, LAngleLoc,
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
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
Parser: Don't manage TemplateAnnotationIds in a delayed cleanup pool. Instead, make it the allocation function's responsibility to add them to a list and clear it when a top-level decl is finished. This plugs leakage of TemplateAnnotationIds. DelayedCleanupPool is ugly and unused, remove it. llvm-svn: 154743
2012-04-14 20:14:03 +08:00
= TemplateIdAnnotation::Allocate(TemplateArgs.size(), TemplateIds);
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
Fix several crash-on-invalids when using template-ids that aren't simple-template-ids (eg, 'operator+<int>') in weird places. llvm-svn: 196333
2013-12-04 08:28:23 +08:00
// FIXME: Store name for literal operator too.
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 (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 {
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
TemplateId->Name = nullptr;
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 = 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 nested-name-specifier source-location information into dependent template specialization types. This also required some parser tweaks, since we were losing track of the nested-name-specifier's source location information in several places in the parser. Other notable changes this required: - Sema::ActOnTagTemplateIdType now type-checks and forms the appropriate type nodes (+ source-location information) for an elaborated-type-specifier ending in a template-id. Previously, we used a combination of ActOnTemplateIdType and ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped around a DependentTemplateSpecializationType, which duplicated the keyword ("class", "struct", etc.) and nested-name-specifier storage. - Sema::ActOnTemplateIdType now gets a nested-name-specifier, which it places into the returned type-source location information. - Sema::ActOnDependentTag now creates types with source-location information. llvm-svn: 126808
2011-03-02 08:47:37 +08:00
TemplateId->SS = SS;
Set the location of the template keyword when allocating a new TemplateIdAnnotation. Found by valgrind. llvm-svn: 150940
2012-02-20 07:37:39 +08:00
TemplateId->TemplateKWLoc = TemplateKWLoc;
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.
Now that ASTMultiPtr is nothing more than a array reference, make it a MutableArrayRef. This required changing all get() calls to data() and using the simpler constructors. llvm-svn: 162501
2012-08-24 07:38:35 +08:00
ASTTemplateArgsPtr TemplateArgsPtr(TemplateArgs);
Avoid redundant NNS qualification in constructor/destructor names. llvm-svn: 149124
2012-01-27 16:46:19 +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
// 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
Added location for template keyword in TemplateSpecializationTypeLoc. In the process removed some naming ambiguities. llvm-svn: 149870
2012-02-06 22:41:24 +08:00
= Actions.ActOnTemplateIdType(SS, TemplateKWLoc,
Template, NameLoc,
Avoid redundant NNS qualification in constructor/destructor names. llvm-svn: 149124
2012-01-27 16:46:19 +08:00
LAngleLoc, TemplateArgsPtr, RAngleLoc,
/*IsCtorOrDtorName=*/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
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
///
Fix a few -Wdocumentation warnings. llvm-svn: 162506
2012-08-24 08:01:24 +08:00
/// \param SS The nested-name-specifier that preceded this unqualified-id. If
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
/// 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();
Disambiguation of '[[': * In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject array sizes and array indexes which begin with a lambda-expression. Recover by parsing the lambda as a lambda. * In Objective-C++11, either '[' could be the start of a message-send. Fully disambiguate this case: it turns out that the grammars of message-sends, lambdas and attributes do not actually overlap. Accept any occurrence of '[[' where either '[' starts a message send, but reject a lambda in an array index just like in C++11 mode. Implement a couple of changes to the attribute wording which occurred after our attributes implementation landed: * In a function-declaration, the attributes go after the exception specification, not after the right paren. * A reference type can have attributes applied. * An 'identifier' in an attribute can also be a keyword. Support for alternative tokens (iso646 keywords) in attributes to follow. And some bug fixes: * Parse attributes after declarator-ids, even if they are not simple identifiers. * Do not accept attributes after a parenthesized declarator. * Accept attributes after an array size in a new-type-id. * Partially disamiguate 'delete' followed by a lambda. More work is required here for the case where the lambda-introducer is '[]'. llvm-svn: 154369
2012-04-10 09:32:12 +08:00
// Check for array new/delete.
if (Tok.is(tok::l_square) &&
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
(!getLangOpts().CPlusPlus11 || NextToken().isNot(tok::l_square))) {
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
// Consume the '[' and ']'.
BalancedDelimiterTracker T(*this, tok::l_square);
T.consumeOpen();
T.consumeClose();
if (T.getCloseLocation().isInvalid())
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;
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
SymbolLocations[SymbolIdx++] = T.getOpenLocation();
SymbolLocations[SymbolIdx++] = T.getCloseLocation();
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
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: {
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
// Consume the '(' and ')'.
BalancedDelimiterTracker T(*this, tok::l_paren);
T.consumeOpen();
T.consumeClose();
if (T.getCloseLocation().isInvalid())
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;
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
SymbolLocations[SymbolIdx++] = T.getOpenLocation();
SymbolLocations[SymbolIdx++] = T.getCloseLocation();
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
Op = OO_Call;
break;
}
case tok::l_square: {
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
// Consume the '[' and ']'.
BalancedDelimiterTracker T(*this, tok::l_square);
T.consumeOpen();
T.consumeClose();
if (T.getCloseLocation().isInvalid())
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;
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
SymbolLocations[SymbolIdx++] = T.getOpenLocation();
SymbolLocations[SymbolIdx++] = T.getCloseLocation();
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
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());
Support code-completion for C++ inline methods and ObjC buffering methods. Previously we would cut off the source file buffer at the code-completion point; this impeded code-completion inside C++ inline methods and, recently, with buffering ObjC methods. Have the code-completion inserted into the source buffer so that it can be buffered along with a method body. When we actually hit the code-completion point the cut-off lexing or parsing. Fixes rdar://10056932&8319466 llvm-svn: 139086
2011-09-04 11:32:15 +08:00
cutOffParsing();
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.
//
DR1473: Do not require a space between operator"" and the ud-suffix in a literal-operator-id. llvm-svn: 166373
2012-10-20 16:41:10 +08:00
// literal-operator-id: C++11 [over.literal]
// operator string-literal identifier
// operator user-defined-string-literal
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
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
if (getLangOpts().CPlusPlus11 && isTokenStringLiteral()) {
Implement -Wc++98-compat warnings for the parser. llvm-svn: 142056
2011-10-15 13:09:34 +08:00
Diag(Tok.getLocation(), diag::warn_cxx98_compat_literal_operator);
Fix a couple of issues with literal-operator-id parsing, and provide recovery for a few kinds of error. Specifically: Since we're after translation phase 6, the "" token might be formed by multiple source-level string literals. Checking the token width is not a correct way of detecting empty string literals, due to escaped newlines. Diagnose and recover from a missing space between "" and suffix, and from string literals other than "", which are followed by a suffix. llvm-svn: 152348
2012-03-09 07:06:02 +08:00
SourceLocation DiagLoc;
unsigned DiagId = 0;
// We're past translation phase 6, so perform string literal concatenation
// before checking for "".
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallVector<Token, 4> Toks;
SmallVector<SourceLocation, 4> TokLocs;
Fix a couple of issues with literal-operator-id parsing, and provide recovery for a few kinds of error. Specifically: Since we're after translation phase 6, the "" token might be formed by multiple source-level string literals. Checking the token width is not a correct way of detecting empty string literals, due to escaped newlines. Diagnose and recover from a missing space between "" and suffix, and from string literals other than "", which are followed by a suffix. llvm-svn: 152348
2012-03-09 07:06:02 +08:00
while (isTokenStringLiteral()) {
if (!Tok.is(tok::string_literal) && !DiagId) {
DR1473: Do not require a space between operator"" and the ud-suffix in a literal-operator-id. llvm-svn: 166373
2012-10-20 16:41:10 +08:00
// C++11 [over.literal]p1:
// The string-literal or user-defined-string-literal in a
// literal-operator-id shall have no encoding-prefix [...].
Fix a couple of issues with literal-operator-id parsing, and provide recovery for a few kinds of error. Specifically: Since we're after translation phase 6, the "" token might be formed by multiple source-level string literals. Checking the token width is not a correct way of detecting empty string literals, due to escaped newlines. Diagnose and recover from a missing space between "" and suffix, and from string literals other than "", which are followed by a suffix. llvm-svn: 152348
2012-03-09 07:06:02 +08:00
DiagLoc = Tok.getLocation();
DiagId = diag::err_literal_operator_string_prefix;
}
Toks.push_back(Tok);
TokLocs.push_back(ConsumeStringToken());
User-defined literals: reject string and character UDLs in all places where the grammar requires a string-literal and not a user-defined-string-literal. The two constructs are still represented by the same TokenKind, in order to prevent a combinatorial explosion of different kinds of token. A flag on Token tracks whether a ud-suffix is present, in order to prevent clients from needing to look at the token's spelling. llvm-svn: 152098
2012-03-06 11:21:47 +08:00
}
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
Convert StringLiteralParser constructor to use ArrayRef instead of a pointer and count. llvm-svn: 211763
2014-06-26 12:58:39 +08:00
StringLiteralParser Literal(Toks, PP);
Fix a couple of issues with literal-operator-id parsing, and provide recovery for a few kinds of error. Specifically: Since we're after translation phase 6, the "" token might be formed by multiple source-level string literals. Checking the token width is not a correct way of detecting empty string literals, due to escaped newlines. Diagnose and recover from a missing space between "" and suffix, and from string literals other than "", which are followed by a suffix. llvm-svn: 152348
2012-03-09 07:06:02 +08:00
if (Literal.hadError)
return true;
// Grab the literal operator's suffix, which will be either the next token
// or a ud-suffix from the string literal.
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
IdentifierInfo *II = nullptr;
Fix a couple of issues with literal-operator-id parsing, and provide recovery for a few kinds of error. Specifically: Since we're after translation phase 6, the "" token might be formed by multiple source-level string literals. Checking the token width is not a correct way of detecting empty string literals, due to escaped newlines. Diagnose and recover from a missing space between "" and suffix, and from string literals other than "", which are followed by a suffix. llvm-svn: 152348
2012-03-09 07:06:02 +08:00
SourceLocation SuffixLoc;
if (!Literal.getUDSuffix().empty()) {
II = &PP.getIdentifierTable().get(Literal.getUDSuffix());
SuffixLoc =
Lexer::AdvanceToTokenCharacter(TokLocs[Literal.getUDSuffixToken()],
Literal.getUDSuffixOffset(),
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
PP.getSourceManager(), getLangOpts());
Fix a couple of issues with literal-operator-id parsing, and provide recovery for a few kinds of error. Specifically: Since we're after translation phase 6, the "" token might be formed by multiple source-level string literals. Checking the token width is not a correct way of detecting empty string literals, due to escaped newlines. Diagnose and recover from a missing space between "" and suffix, and from string literals other than "", which are followed by a suffix. llvm-svn: 152348
2012-03-09 07:06:02 +08:00
} else if (Tok.is(tok::identifier)) {
II = Tok.getIdentifierInfo();
SuffixLoc = ConsumeToken();
TokLocs.push_back(SuffixLoc);
} else {
Support and use token kinds as diagnostic arguments Introduce proper facilities to render token spellings using the diagnostic formatter. Replaces most of the hard-coded diagnostic messages related to expected tokens, which all shared the same semantics but had to be multiply defined due to variations in token order or quote marks. The associated parser changes are largely mechanical but they expose commonality in whole chunks of the parser that can now be factored away. This commit uses C++11 typed enums along with a speculative legacy fallback until the transition is complete. Requires corresponding changes in LLVM r197895. llvm-svn: 197972
2013-12-24 17:48:30 +08:00
Diag(Tok.getLocation(), diag::err_expected) << tok::identifier;
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
return true;
}
Fix a couple of issues with literal-operator-id parsing, and provide recovery for a few kinds of error. Specifically: Since we're after translation phase 6, the "" token might be formed by multiple source-level string literals. Checking the token width is not a correct way of detecting empty string literals, due to escaped newlines. Diagnose and recover from a missing space between "" and suffix, and from string literals other than "", which are followed by a suffix. llvm-svn: 152348
2012-03-09 07:06:02 +08:00
// The string literal must be empty.
if (!Literal.GetString().empty() || Literal.Pascal) {
DR1473: Do not require a space between operator"" and the ud-suffix in a literal-operator-id. llvm-svn: 166373
2012-10-20 16:41:10 +08:00
// C++11 [over.literal]p1:
// The string-literal or user-defined-string-literal in a
// literal-operator-id shall [...] contain no characters
// other than the implicit terminating '\0'.
Fix a couple of issues with literal-operator-id parsing, and provide recovery for a few kinds of error. Specifically: Since we're after translation phase 6, the "" token might be formed by multiple source-level string literals. Checking the token width is not a correct way of detecting empty string literals, due to escaped newlines. Diagnose and recover from a missing space between "" and suffix, and from string literals other than "", which are followed by a suffix. llvm-svn: 152348
2012-03-09 07:06:02 +08:00
DiagLoc = TokLocs.front();
DiagId = diag::err_literal_operator_string_not_empty;
}
if (DiagId) {
// This isn't a valid literal-operator-id, but we think we know
// what the user meant. Tell them what they should have written.
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallString<32> Str;
Fix a couple of issues with literal-operator-id parsing, and provide recovery for a few kinds of error. Specifically: Since we're after translation phase 6, the "" token might be formed by multiple source-level string literals. Checking the token width is not a correct way of detecting empty string literals, due to escaped newlines. Diagnose and recover from a missing space between "" and suffix, and from string literals other than "", which are followed by a suffix. llvm-svn: 152348
2012-03-09 07:06:02 +08:00
Str += "\"\" ";
Str += II->getName();
Diag(DiagLoc, DiagId) << FixItHint::CreateReplacement(
SourceRange(TokLocs.front(), TokLocs.back()), Str);
}
Result.setLiteralOperatorId(II, KeywordLoc, SuffixLoc);
Reject template-ids containing literal-operator-ids that have a dependent nested-name-specifier, rather than crashing. (In fact, reject all literal-operator-ids that have a non-namespace nested-name-specifier). The grammar doesn't allow these in some cases, and in other cases does allow them but instantiation will always fail. llvm-svn: 196443
2013-12-05 08:58:33 +08:00
return Actions.checkLiteralOperatorId(SS, Result);
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
}
Reject template-ids containing literal-operator-ids that have a dependent nested-name-specifier, rather than crashing. (In fact, reject all literal-operator-ids that have a non-namespace nested-name-specifier). The grammar doesn't allow these in some cases, and in other cases does allow them but instantiation will always fail. llvm-svn: 196443
2013-12-05 08:58:33 +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.
Insomniac refactoring: change how the parser allocates attributes so that AttributeLists do not accumulate over the lifetime of parsing, but are instead reused. Also make the arguments array not require a separate allocation, and make availability attributes store their stuff in augmented memory, too. llvm-svn: 128209
2011-03-24 19:26:52 +08:00
DeclSpec DS(AttrFactory);
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.
Separate out and special-case the diagnostic for 'auto' in a conversion-type-id, in preparation for this becoming valid in c++1y mode. No functionality change; small diagnostic improvement. llvm-svn: 181089
2013-05-04 09:26:46 +08:00
Declarator D(DS, Declarator::ConversionIdContext);
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
ParseDeclaratorInternal(D, /*DirectDeclParser=*/nullptr);
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
// 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
///
Fix a few -Wdocumentation warnings. llvm-svn: 162506
2012-08-24 08:01:24 +08:00
/// \param SS The nested-name-specifier that preceded this unqualified-id. If
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
/// 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,
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
SourceLocation& 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
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;
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (getLangOpts().CPlusPlus && Tok.is(tok::kw_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
(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();
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (!getLangOpts().CPlusPlus) {
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 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.
Avoid redundant NNS qualification in constructor/destructor names. llvm-svn: 149124
2012-01-27 16:46:19 +08:00
ParsedType Ty = Actions.getTypeName(*Id, IdLoc, getCurScope(),
&SS, false, false,
ParsedType(),
/*IsCtorOrDtorName=*/true,
/*NonTrivialTypeSourceInfo=*/true);
Result.setConstructorName(Ty, IdLoc, IdLoc);
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
} 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))
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
return ParseUnqualifiedIdTemplateId(SS, TemplateKWLoc, Id, IdLoc,
EnteringContext, ObjectType,
Result, TemplateSpecified);
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)) {
Introduce DelayedCleanupPool useful for simplifying clean-up of certain resources that, while their lifetime is well-known and restricted, cleaning them up manually is easy to miss and cause a leak. Use it to plug the leaking of TemplateIdAnnotation objects. rdar://9634138. llvm-svn: 133610
2011-06-22 14:09:49 +08:00
TemplateIdAnnotation *TemplateId = takeTemplateIdAnnotation(Tok);
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 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));
Avoid redundant NNS qualification in constructor/destructor names. llvm-svn: 149124
2012-01-27 16:46:19 +08:00
ParsedType Ty = Actions.getTypeName(*TemplateId->Name,
TemplateId->TemplateNameLoc,
getCurScope(),
&SS, false, false,
ParsedType(),
/*IsCtorOrDtorName=*/true,
/*NontrivialTypeSourceInfo=*/true);
Result.setConstructorName(Ty, TemplateId->TemplateNameLoc,
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
TemplateId->RAngleLoc);
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);
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
TemplateKWLoc = TemplateId->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
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)))
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
return ParseUnqualifiedIdTemplateId(SS, TemplateKWLoc,
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
nullptr, SourceLocation(),
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
EnteringContext, ObjectType,
Result, TemplateSpecified);
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +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
return false;
}
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
if (getLangOpts().CPlusPlus &&
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
(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();
Decltype in non-pseudo (& non-dependent) dtor calls. llvm-svn: 146155
2011-12-09 00:13:53 +08:00
if (SS.isEmpty() && Tok.is(tok::kw_decltype)) {
DeclSpec DS(AttrFactory);
SourceLocation EndLoc = ParseDecltypeSpecifier(DS);
if (ParsedType Type = Actions.getDestructorType(DS, ObjectType)) {
Result.setDestructorName(TildeLoc, Type, EndLoc);
return false;
}
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
// 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;
}
Add error, recovery and fixit for "~A::A() {...}". llvm-svn: 217302
2014-09-06 10:06:12 +08:00
// If the user wrote ~T::T, correct it to T::~T.
if (!TemplateSpecified && NextToken().is(tok::coloncolon)) {
if (SS.isSet()) {
AnnotateScopeToken(SS, /*NewAnnotation*/true);
SS.clear();
}
if (ParseOptionalCXXScopeSpecifier(SS, ObjectType, EnteringContext))
return true;
if (Tok.isNot(tok::identifier) || NextToken().is(tok::coloncolon)) {
Diag(TildeLoc, diag::err_destructor_tilde_scope);
return true;
}
// Recover as if the tilde had been written before the identifier.
Diag(TildeLoc, diag::err_destructor_tilde_scope)
<< FixItHint::CreateRemoval(TildeLoc)
<< FixItHint::CreateInsertion(Tok.getLocation(), "~");
}
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
// Parse the class-name (or template-name in a simple-template-id).
IdentifierInfo *ClassName = Tok.getIdentifierInfo();
SourceLocation ClassNameLoc = ConsumeToken();
Add error, recovery and fixit for "~A::A() {...}". llvm-svn: 217302
2014-09-06 10:06:12 +08:00
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);
Added source location for the template keyword in AST template-id expressions. llvm-svn: 149127
2012-01-27 17:46:47 +08:00
return ParseUnqualifiedIdTemplateId(SS, TemplateKWLoc,
ClassName, ClassNameLoc,
EnteringContext, ObjectType,
Result, TemplateSpecified);
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
}
Add error, recovery and fixit for "~A::A() {...}". llvm-svn: 217302
2014-09-06 10:06:12 +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)
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
<< getLangOpts().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]
Parse GNU-style attributes prior to the type-id/new-type-id in a C++ "new" expression. This matches GCC's parser. Test is forthcoming. llvm-svn: 129592
2011-04-16 03:40:02 +08:00
/// [GNU] attributes type-specifier-seq new-declarator[opt]
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-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] ')'
Parse C++0x generalized initializers. llvm-svn: 132662
2011-06-05 20:23:16 +08:00
/// [C++0x] braced-init-list
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
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.
Remove ASTOwningVector, it doesn't own anything and provides no value over SmallVector. llvm-svn: 162492
2012-08-24 06:51:59 +08:00
ExprVector PlacementArgs;
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;
Insomniac refactoring: change how the parser allocates attributes so that AttributeLists do not accumulate over the lifetime of parsing, but are instead reused. Also make the arguments array not require a separate allocation, and make availability attributes store their stuff in augmented memory, too. llvm-svn: 128209
2011-03-24 19:26:52 +08:00
DeclSpec DS(AttrFactory);
Introduce Declarator::CXXNewContext and remove 'AutoAllowedInTypeName' parameter from Sema::GetTypeForDeclarator. No functionality change. llvm-svn: 133987
2011-06-28 11:01:23 +08:00
Declarator DeclaratorInfo(DS, Declarator::CXXNewContext);
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.
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren);
T.consumeOpen();
PlacementLParen = T.getOpenLocation();
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)) {
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::semi, StopAtSemi | StopBeforeMatch);
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
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
PlacementRParen = T.getCloseLocation();
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()) {
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::semi, StopAtSemi | StopBeforeMatch);
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.
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
TypeIdParens = T.getRange();
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)) {
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren);
T.consumeOpen();
Parse GNU-style attributes prior to the type-id/new-type-id in a C++ "new" expression. This matches GCC's parser. Test is forthcoming. llvm-svn: 129592
2011-04-16 03:40:02 +08:00
MaybeParseGNUAttributes(DeclaratorInfo);
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);
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
TypeIdParens = T.getRange();
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 {
Parse GNU-style attributes prior to the type-id/new-type-id in a C++ "new" expression. This matches GCC's parser. Test is forthcoming. llvm-svn: 129592
2011-04-16 03:40:02 +08:00
MaybeParseGNUAttributes(DeclaratorInfo);
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.
Parse GNU-style attributes prior to the type-id/new-type-id in a C++ "new" expression. This matches GCC's parser. Test is forthcoming. llvm-svn: 129592
2011-04-16 03:40:02 +08:00
MaybeParseGNUAttributes(DeclaratorInfo);
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
}
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()) {
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::semi, StopAtSemi | StopBeforeMatch);
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
Revert "Revert "Make CXXNewExpr contain only a single initialier, and not hold the used constructor itself."" This reintroduces commit r150682 with a fix for the Bullet benchmark crash. llvm-svn: 150685
2012-02-16 20:22:20 +08:00
ExprResult Initializer;
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)) {
Revert "Revert "Make CXXNewExpr contain only a single initialier, and not hold the used constructor itself."" This reintroduces commit r150682 with a fix for the Bullet benchmark crash. llvm-svn: 150685
2012-02-16 20:22:20 +08:00
SourceLocation ConstructorLParen, ConstructorRParen;
Remove ASTOwningVector, it doesn't own anything and provides no value over SmallVector. llvm-svn: 162492
2012-08-24 06:51:59 +08:00
ExprVector ConstructorArgs;
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren);
T.consumeOpen();
ConstructorLParen = T.getOpenLocation();
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.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)) {
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::semi, StopAtSemi | StopBeforeMatch);
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
}
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
ConstructorRParen = T.getCloseLocation();
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()) {
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::semi, StopAtSemi | StopBeforeMatch);
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
}
Revert "Revert "Make CXXNewExpr contain only a single initialier, and not hold the used constructor itself."" This reintroduces commit r150682 with a fix for the Bullet benchmark crash. llvm-svn: 150685
2012-02-16 20:22:20 +08:00
Initializer = Actions.ActOnParenListExpr(ConstructorLParen,
ConstructorRParen,
Rip out remnants of move semantic emulation and smart pointers in Sema. These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
2012-08-24 05:35:17 +08:00
ConstructorArgs);
s/CPlusPlus0x/CPlusPlus11/g llvm-svn: 171367
2013-01-02 19:42:31 +08:00
} else if (Tok.is(tok::l_brace) && getLangOpts().CPlusPlus11) {
Implement -Wc++98-compat warnings for the parser. llvm-svn: 142056
2011-10-15 13:09:34 +08:00
Diag(Tok.getLocation(),
diag::warn_cxx98_compat_generalized_initializer_lists);
Revert "Revert "Make CXXNewExpr contain only a single initialier, and not hold the used constructor itself."" This reintroduces commit r150682 with a fix for the Bullet benchmark crash. llvm-svn: 150685
2012-02-16 20:22:20 +08:00
Initializer = ParseBraceInitializer();
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
}
Revert "Revert "Make CXXNewExpr contain only a single initialier, and not hold the used constructor itself."" This reintroduces commit r150682 with a fix for the Bullet benchmark crash. llvm-svn: 150685
2012-02-16 20:22:20 +08:00
if (Initializer.isInvalid())
return Initializer;
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,
Rip out remnants of move semantic emulation and smart pointers in Sema. These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
2012-08-24 05:35:17 +08:00
PlacementArgs, PlacementRParen,
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
TypeIdParens, DeclaratorInfo, Initializer.get());
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)) {
Disambiguation of '[[': * In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject array sizes and array indexes which begin with a lambda-expression. Recover by parsing the lambda as a lambda. * In Objective-C++11, either '[' could be the start of a message-send. Fully disambiguate this case: it turns out that the grammars of message-sends, lambdas and attributes do not actually overlap. Accept any occurrence of '[[' where either '[' starts a message send, but reject a lambda in an array index just like in C++11 mode. Implement a couple of changes to the attribute wording which occurred after our attributes implementation landed: * In a function-declaration, the attributes go after the exception specification, not after the right paren. * A reference type can have attributes applied. * An 'identifier' in an attribute can also be a keyword. Support for alternative tokens (iso646 keywords) in attributes to follow. And some bug fixes: * Parse attributes after declarator-ids, even if they are not simple identifiers. * Do not accept attributes after a parenthesized declarator. * Accept attributes after an array size in a new-type-id. * Partially disamiguate 'delete' followed by a lambda. More work is required here for the case where the lambda-introducer is '[]'. llvm-svn: 154369
2012-04-10 09:32:12 +08:00
// An array-size expression can't start with a lambda.
if (CheckProhibitedCXX11Attribute())
continue;
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_square);
T.consumeOpen();
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
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::r_square, StopAtSemi);
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;
}
first = false;
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
Insomniac refactoring: change how the parser allocates attributes so that AttributeLists do not accumulate over the lifetime of parsing, but are instead reused. Also make the arguments array not require a separate allocation, and make availability attributes store their stuff in augmented memory, too. llvm-svn: 128209
2011-03-24 19:26:52 +08:00
Revert r170500. It over-zealously converted *ALL* things named Attributes, which is wrong here. llvm-svn: 170721
2012-12-21 03:22:21 +08:00
// Attributes here appertain to the array type. C++11 [expr.new]p5.
Disambiguation of '[[': * In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject array sizes and array indexes which begin with a lambda-expression. Recover by parsing the lambda as a lambda. * In Objective-C++11, either '[' could be the start of a message-send. Fully disambiguate this case: it turns out that the grammars of message-sends, lambdas and attributes do not actually overlap. Accept any occurrence of '[[' where either '[' starts a message send, but reject a lambda in an array index just like in C++11 mode. Implement a couple of changes to the attribute wording which occurred after our attributes implementation landed: * In a function-declaration, the attributes go after the exception specification, not after the right paren. * A reference type can have attributes applied. * An 'identifier' in an attribute can also be a keyword. Support for alternative tokens (iso646 keywords) in attributes to follow. And some bug fixes: * Parse attributes after declarator-ids, even if they are not simple identifiers. * Do not accept attributes after a parenthesized declarator. * Accept attributes after an array size in a new-type-id. * Partially disamiguate 'delete' followed by a lambda. More work is required here for the case where the lambda-introducer is '[]'. llvm-svn: 154369
2012-04-10 09:32:12 +08:00
ParsedAttributes Attrs(AttrFactory);
s/CXX0X/CXX11/g, except for __GNU_EXPERIMENTAL_CXX0X__, and update a few nearby 'C++0x' comments. llvm-svn: 171372
2013-01-02 20:01:23 +08:00
MaybeParseCXX11Attributes(Attrs);
Disambiguation of '[[': * In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject array sizes and array indexes which begin with a lambda-expression. Recover by parsing the lambda as a lambda. * In Objective-C++11, either '[' could be the start of a message-send. Fully disambiguate this case: it turns out that the grammars of message-sends, lambdas and attributes do not actually overlap. Accept any occurrence of '[[' where either '[' starts a message send, but reject a lambda in an array index just like in C++11 mode. Implement a couple of changes to the attribute wording which occurred after our attributes implementation landed: * In a function-declaration, the attributes go after the exception specification, not after the right paren. * A reference type can have attributes applied. * An 'identifier' in an attribute can also be a keyword. Support for alternative tokens (iso646 keywords) in attributes to follow. And some bug fixes: * Parse attributes after declarator-ids, even if they are not simple identifiers. * Do not accept attributes after a parenthesized declarator. * Accept attributes after an array size in a new-type-id. * Partially disamiguate 'delete' followed by a lambda. More work is required here for the case where the lambda-introducer is '[]'. llvm-svn: 154369
2012-04-10 09:32:12 +08:00
Insomniac refactoring: change how the parser allocates attributes so that AttributeLists do not accumulate over the lifetime of parsing, but are instead reused. Also make the arguments array not require a separate allocation, and make availability attributes store their stuff in augmented memory, too. llvm-svn: 128209
2011-03-24 19:26:52 +08:00
D.AddTypeInfo(DeclaratorChunk::getArray(0,
Refactor how we collect attributes during parsing, and add slots for attributes on array and function declarators. This is pretty far from complete, and I'll revisit it later if someone doesn't beat me to it. llvm-svn: 122535
2010-12-24 10:08:15 +08:00
/*static=*/false, /*star=*/false,
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Size.get(),
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.getOpenLocation(),
T.getCloseLocation()),
Disambiguation of '[[': * In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject array sizes and array indexes which begin with a lambda-expression. Recover by parsing the lambda as a lambda. * In Objective-C++11, either '[' could be the start of a message-send. Fully disambiguate this case: it turns out that the grammars of message-sends, lambdas and attributes do not actually overlap. Accept any occurrence of '[[' where either '[' starts a message send, but reject a lambda in an array index just like in C++11 mode. Implement a couple of changes to the attribute wording which occurred after our attributes implementation landed: * In a function-declaration, the attributes go after the exception specification, not after the right paren. * A reference type can have attributes applied. * An 'identifier' in an attribute can also be a keyword. Support for alternative tokens (iso646 keywords) in attributes to follow. And some bug fixes: * Parse attributes after declarator-ids, even if they are not simple identifiers. * Do not accept attributes after a parenthesized declarator. * Accept attributes after an array size in a new-type-id. * Partially disamiguate 'delete' followed by a lambda. More work is required here for the case where the lambda-introducer is '[]'. llvm-svn: 154369
2012-04-10 09:32:12 +08:00
Attrs, T.getCloseLocation());
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
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
if (T.getCloseLocation().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(
remove unneeded llvm:: namespace qualifiers on some core types now that LLVM.h imports them into the clang namespace. llvm-svn: 135852
2011-07-23 18:55:15 +08:00
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;
Disambiguation of '[[': * In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject array sizes and array indexes which begin with a lambda-expression. Recover by parsing the lambda as a lambda. * In Objective-C++11, either '[' could be the start of a message-send. Fully disambiguate this case: it turns out that the grammars of message-sends, lambdas and attributes do not actually overlap. Accept any occurrence of '[[' where either '[' starts a message send, but reject a lambda in an array index just like in C++11 mode. Implement a couple of changes to the attribute wording which occurred after our attributes implementation landed: * In a function-declaration, the attributes go after the exception specification, not after the right paren. * A reference type can have attributes applied. * An 'identifier' in an attribute can also be a keyword. Support for alternative tokens (iso646 keywords) in attributes to follow. And some bug fixes: * Parse attributes after declarator-ids, even if they are not simple identifiers. * Do not accept attributes after a parenthesized declarator. * Accept attributes after an array size in a new-type-id. * Partially disamiguate 'delete' followed by a lambda. More work is required here for the case where the lambda-introducer is '[]'. llvm-svn: 154369
2012-04-10 09:32:12 +08:00
if (Tok.is(tok::l_square) && NextToken().is(tok::r_square)) {
In 'delete []', the '[]' never starts a lambda. Update a FIXME with a standard reference and add a test. llvm-svn: 161604
2012-08-10 03:01:51 +08:00
// C++11 [expr.delete]p1:
// Whenever the delete keyword is followed by empty square brackets, it
// shall be interpreted as [array delete].
// [Footnote: A lambda expression with a lambda-introducer that consists
// of empty square brackets can follow the delete keyword if
// the lambda expression is enclosed in parentheses.]
// FIXME: Produce a better diagnostic if the '[]' is unambiguously a
// lambda-introducer.
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
ArrayDelete = true;
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_square);
T.consumeOpen();
T.consumeClose();
if (T.getCloseLocation().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())
Rip out remnants of move semantic emulation and smart pointers in Sema. These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
2012-08-24 05:35:17 +08:00
return 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
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
return Actions.ActOnCXXDelete(Start, UseGlobal, ArrayDelete, Operand.get());
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
Implement a new type trait __is_trivially_constructible(T, Args...) that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
2012-02-24 15:38:34 +08:00
static TypeTrait TypeTraitFromTokKind(tok::TokenKind kind) {
switch (kind) {
default: llvm_unreachable("Not a known type trait");
Eliminate UnaryTypeTraitExpr Remove UnaryTypeTraitExpr and switch all remaining type trait related handling over to TypeTraitExpr. The UTT/BTT/TT enum prefix and evaluation code is retained pending further cleanup. This is part of the ongoing work to unify type traits following the removal of BinaryTypeTraitExpr in r197273. llvm-svn: 198271
2014-01-01 13:57:51 +08:00
#define TYPE_TRAIT_1(Spelling, Name, Key) \
case tok::kw_ ## Spelling: return UTT_ ## Name;
Eliminate BinaryTypeTraitExpr There's nothing special about type traits accepting two arguments. This commit eliminates BinaryTypeTraitExpr and switches all related handling over to TypeTraitExpr. Also fixes a CodeGen failure with variadic type traits appearing in a non-constant expression. The BTT/TT prefix and evaluation code is retained as-is for now but will soon be further cleaned up. This is part of the ongoing work to unify type traits. llvm-svn: 197273
2013-12-14 04:49:58 +08:00
#define TYPE_TRAIT_2(Spelling, Name, Key) \
case tok::kw_ ## Spelling: return BTT_ ## Name;
#include "clang/Basic/TokenKinds.def"
Unify type trait parsing Type trait parsing is all over the place at the moment with unary, binary and n-ary C++11 type traits that were developed independently at different points in clang's history. There's no good reason to handle them separately -- there are three parsers, three AST nodes and lots of duplicated handling code with slightly different implementations and diags for each kind. This commit unifies parsing of type traits and sets the stage for further consolidation. No change in behaviour other than more consistent error recovery. llvm-svn: 197179
2013-12-13 05:23:03 +08:00
#define TYPE_TRAIT_N(Spelling, Name, Key) \
case tok::kw_ ## Spelling: return TT_ ## Name;
#include "clang/Basic/TokenKinds.def"
Implement a new type trait __is_trivially_constructible(T, Args...) that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
2012-02-24 15:38:34 +08:00
}
}
Implementation of Embarcadero array type traits Patch authored by John Wiegley. These are array type traits used for parsing code that employs certain features of the Embarcadero C++ compiler: __array_rank(T) and __array_extent(T, Dim). llvm-svn: 130351
2011-04-28 08:16:57 +08:00
static ArrayTypeTrait ArrayTypeTraitFromTokKind(tok::TokenKind kind) {
switch(kind) {
default: llvm_unreachable("Not a known binary type trait");
case tok::kw___array_rank: return ATT_ArrayRank;
case tok::kw___array_extent: return ATT_ArrayExtent;
}
}
t/clang/expr-traits Patch authored by David Abrahams. These two expression traits (__is_lvalue_expr, __is_rvalue_expr) are used for parsing code that employs certain features of the Embarcadero C++ compiler. llvm-svn: 130122
2011-04-25 14:54:41 +08:00
static ExpressionTrait ExpressionTraitFromTokKind(tok::TokenKind kind) {
switch(kind) {
Switch assert(0/false) llvm_unreachable. llvm-svn: 140367
2011-09-23 13:06:16 +08:00
default: llvm_unreachable("Not a known unary expression trait.");
t/clang/expr-traits Patch authored by David Abrahams. These two expression traits (__is_lvalue_expr, __is_rvalue_expr) are used for parsing code that employs certain features of the Embarcadero C++ compiler. llvm-svn: 130122
2011-04-25 14:54:41 +08:00
case tok::kw___is_lvalue_expr: return ET_IsLValueExpr;
case tok::kw___is_rvalue_expr: return ET_IsRValueExpr;
}
}
Unify type trait parsing Type trait parsing is all over the place at the moment with unary, binary and n-ary C++11 type traits that were developed independently at different points in clang's history. There's no good reason to handle them separately -- there are three parsers, three AST nodes and lots of duplicated handling code with slightly different implementations and diags for each kind. This commit unifies parsing of type traits and sets the stage for further consolidation. No change in behaviour other than more consistent error recovery. llvm-svn: 197179
2013-12-13 05:23:03 +08:00
static unsigned TypeTraitArity(tok::TokenKind kind) {
switch (kind) {
default: llvm_unreachable("Not a known type trait");
#define TYPE_TRAIT(N,Spelling,K) case tok::kw_##Spelling: return N;
#include "clang/Basic/TokenKinds.def"
Type traits intrinsic implementation: __is_base_of(T, U) New AST node introduced: BinaryTypeTraitExpr; to be reused for more intrinsics. llvm-svn: 121074
2010-12-07 08:08:36 +08:00
}
}
Implement a new type trait __is_trivially_constructible(T, Args...) that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
2012-02-24 15:38:34 +08:00
/// \brief Parse the built-in type-trait pseudo-functions that allow
/// implementation of the TR1/C++11 type traits templates.
///
/// primary-expression:
Unify type trait parsing Type trait parsing is all over the place at the moment with unary, binary and n-ary C++11 type traits that were developed independently at different points in clang's history. There's no good reason to handle them separately -- there are three parsers, three AST nodes and lots of duplicated handling code with slightly different implementations and diags for each kind. This commit unifies parsing of type traits and sets the stage for further consolidation. No change in behaviour other than more consistent error recovery. llvm-svn: 197179
2013-12-13 05:23:03 +08:00
/// unary-type-trait '(' type-id ')'
/// binary-type-trait '(' type-id ',' type-id ')'
Implement a new type trait __is_trivially_constructible(T, Args...) that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
2012-02-24 15:38:34 +08:00
/// type-trait '(' type-id-seq ')'
///
/// type-id-seq:
/// type-id ...[opt] type-id-seq[opt]
///
ExprResult Parser::ParseTypeTrait() {
Unify type trait parsing Type trait parsing is all over the place at the moment with unary, binary and n-ary C++11 type traits that were developed independently at different points in clang's history. There's no good reason to handle them separately -- there are three parsers, three AST nodes and lots of duplicated handling code with slightly different implementations and diags for each kind. This commit unifies parsing of type traits and sets the stage for further consolidation. No change in behaviour other than more consistent error recovery. llvm-svn: 197179
2013-12-13 05:23:03 +08:00
tok::TokenKind Kind = Tok.getKind();
unsigned Arity = TypeTraitArity(Kind);
Implement a new type trait __is_trivially_constructible(T, Args...) that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
2012-02-24 15:38:34 +08:00
SourceLocation Loc = ConsumeToken();
BalancedDelimiterTracker Parens(*this, tok::l_paren);
ExpectAndConsume: Diagnose errors automatically 1) Teach ExpectAndConsume() to emit expected and expected-after diagnostics using the generic diagnostic descriptions added in r197972, eliminating another set of trivial err_expected_* variations while maintaining existing behaviour. 2) Lift SkipUntil() recovery out of ExpectAndConsume(). The Expect/Consume family of functions are primitive parser operations that now have the well-defined property of operating on single tokens. Factoring out recovery exposes opportunities for more consistent and tailored error recover at the call sites instead of just relying on a bottled SkipUntil formula. llvm-svn: 198270
2014-01-01 11:08:43 +08:00
if (Parens.expectAndConsume())
Implement a new type trait __is_trivially_constructible(T, Args...) that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
2012-02-24 15:38:34 +08:00
return ExprError();
Remove useless 'llvm::' qualifier from names like StringRef and others that are brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
2013-01-13 03:30:44 +08:00
SmallVector<ParsedType, 2> Args;
Implement a new type trait __is_trivially_constructible(T, Args...) that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
2012-02-24 15:38:34 +08:00
do {
// Parse the next type.
TypeResult Ty = ParseTypeName();
if (Ty.isInvalid()) {
Parens.skipToEnd();
return ExprError();
}
// Parse the ellipsis, if present.
if (Tok.is(tok::ellipsis)) {
Ty = Actions.ActOnPackExpansion(Ty.get(), ConsumeToken());
if (Ty.isInvalid()) {
Parens.skipToEnd();
return ExprError();
}
}
// Add this type to the list of arguments.
Args.push_back(Ty.get());
Refactor and micro-optimize ConsumeToken() 1) Introduce TryConsumeToken() to handle the common test-and-consume pattern. This brings about readability improvements in the parser and optimizes to avoid redundant checks in the common case. 2) Eliminate the ConsumeCodeCompletionTok special case from ConsumeToken(). This was used by only one caller which has been switched over to the more appropriate ConsumeCodeCompletionToken() function. llvm-svn: 197497
2013-12-17 22:12:37 +08:00
} while (TryConsumeToken(tok::comma));
Implement a new type trait __is_trivially_constructible(T, Args...) that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
2012-02-24 15:38:34 +08:00
if (Parens.consumeClose())
return ExprError();
Unify type trait parsing Type trait parsing is all over the place at the moment with unary, binary and n-ary C++11 type traits that were developed independently at different points in clang's history. There's no good reason to handle them separately -- there are three parsers, three AST nodes and lots of duplicated handling code with slightly different implementations and diags for each kind. This commit unifies parsing of type traits and sets the stage for further consolidation. No change in behaviour other than more consistent error recovery. llvm-svn: 197179
2013-12-13 05:23:03 +08:00
SourceLocation EndLoc = Parens.getCloseLocation();
if (Arity && Args.size() != Arity) {
Diag(EndLoc, diag::err_type_trait_arity)
<< Arity << 0 << (Arity > 1) << (int)Args.size() << SourceRange(Loc);
return ExprError();
}
if (!Arity && Args.empty()) {
Diag(EndLoc, diag::err_type_trait_arity)
<< 1 << 1 << 1 << (int)Args.size() << SourceRange(Loc);
return ExprError();
}
Remove an unused parameter and include after r197273 llvm-svn: 197274
2013-12-14 05:19:30 +08:00
return Actions.ActOnTypeTrait(TypeTraitFromTokKind(Kind), Loc, Args, EndLoc);
Implement a new type trait __is_trivially_constructible(T, Args...) that provides the behavior of the C++11 library trait std::is_trivially_constructible<T, Args...>, which can't be implemented purely as a library. Since __is_trivially_constructible can have zero or more arguments, I needed to add Yet Another Type Trait Expression Class, this one handling arbitrary arguments. The next step will be to migrate UnaryTypeTrait and BinaryTypeTrait over to this new, more general TypeTrait class. Fixes the Clang side of <rdar://problem/10895483> / PR12038. llvm-svn: 151352
2012-02-24 15:38:34 +08:00
}
Implementation of Embarcadero array type traits Patch authored by John Wiegley. These are array type traits used for parsing code that employs certain features of the Embarcadero C++ compiler: __array_rank(T) and __array_extent(T, Dim). llvm-svn: 130351
2011-04-28 08:16:57 +08:00
/// ParseArrayTypeTrait - Parse the built-in array type-trait
/// pseudo-functions.
///
/// primary-expression:
/// [Embarcadero] '__array_rank' '(' type-id ')'
/// [Embarcadero] '__array_extent' '(' type-id ',' expression ')'
///
ExprResult Parser::ParseArrayTypeTrait() {
ArrayTypeTrait ATT = ArrayTypeTraitFromTokKind(Tok.getKind());
SourceLocation Loc = ConsumeToken();
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren);
ExpectAndConsume: Diagnose errors automatically 1) Teach ExpectAndConsume() to emit expected and expected-after diagnostics using the generic diagnostic descriptions added in r197972, eliminating another set of trivial err_expected_* variations while maintaining existing behaviour. 2) Lift SkipUntil() recovery out of ExpectAndConsume(). The Expect/Consume family of functions are primitive parser operations that now have the well-defined property of operating on single tokens. Factoring out recovery exposes opportunities for more consistent and tailored error recover at the call sites instead of just relying on a bottled SkipUntil formula. llvm-svn: 198270
2014-01-01 11:08:43 +08:00
if (T.expectAndConsume())
Implementation of Embarcadero array type traits Patch authored by John Wiegley. These are array type traits used for parsing code that employs certain features of the Embarcadero C++ compiler: __array_rank(T) and __array_extent(T, Dim). llvm-svn: 130351
2011-04-28 08:16:57 +08:00
return ExprError();
TypeResult Ty = ParseTypeName();
if (Ty.isInvalid()) {
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::comma, StopAtSemi);
SkipUntil(tok::r_paren, StopAtSemi);
Implementation of Embarcadero array type traits Patch authored by John Wiegley. These are array type traits used for parsing code that employs certain features of the Embarcadero C++ compiler: __array_rank(T) and __array_extent(T, Dim). llvm-svn: 130351
2011-04-28 08:16:57 +08:00
return ExprError();
}
switch (ATT) {
case ATT_ArrayRank: {
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
[C++11] Use 'nullptr'. Parser edition. llvm-svn: 209275
2014-05-21 14:02:52 +08:00
return Actions.ActOnArrayTypeTrait(ATT, Loc, Ty.get(), nullptr,
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.getCloseLocation());
Implementation of Embarcadero array type traits Patch authored by John Wiegley. These are array type traits used for parsing code that employs certain features of the Embarcadero C++ compiler: __array_rank(T) and __array_extent(T, Dim). llvm-svn: 130351
2011-04-28 08:16:57 +08:00
}
case ATT_ArrayExtent: {
ExpectAndConsume: Diagnose errors automatically 1) Teach ExpectAndConsume() to emit expected and expected-after diagnostics using the generic diagnostic descriptions added in r197972, eliminating another set of trivial err_expected_* variations while maintaining existing behaviour. 2) Lift SkipUntil() recovery out of ExpectAndConsume(). The Expect/Consume family of functions are primitive parser operations that now have the well-defined property of operating on single tokens. Factoring out recovery exposes opportunities for more consistent and tailored error recover at the call sites instead of just relying on a bottled SkipUntil formula. llvm-svn: 198270
2014-01-01 11:08:43 +08:00
if (ExpectAndConsume(tok::comma)) {
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::r_paren, StopAtSemi);
Implementation of Embarcadero array type traits Patch authored by John Wiegley. These are array type traits used for parsing code that employs certain features of the Embarcadero C++ compiler: __array_rank(T) and __array_extent(T, Dim). llvm-svn: 130351
2011-04-28 08:16:57 +08:00
return ExprError();
}
ExprResult DimExpr = ParseExpression();
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
Implementation of Embarcadero array type traits Patch authored by John Wiegley. These are array type traits used for parsing code that employs certain features of the Embarcadero C++ compiler: __array_rank(T) and __array_extent(T, Dim). llvm-svn: 130351
2011-04-28 08:16:57 +08:00
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
return Actions.ActOnArrayTypeTrait(ATT, Loc, Ty.get(), DimExpr.get(),
T.getCloseLocation());
Implementation of Embarcadero array type traits Patch authored by John Wiegley. These are array type traits used for parsing code that employs certain features of the Embarcadero C++ compiler: __array_rank(T) and __array_extent(T, Dim). llvm-svn: 130351
2011-04-28 08:16:57 +08:00
}
}
More dead code removal (using -Wunreachable-code) llvm-svn: 148577
2012-01-21 05:50:17 +08:00
llvm_unreachable("Invalid ArrayTypeTrait!");
Implementation of Embarcadero array type traits Patch authored by John Wiegley. These are array type traits used for parsing code that employs certain features of the Embarcadero C++ compiler: __array_rank(T) and __array_extent(T, Dim). llvm-svn: 130351
2011-04-28 08:16:57 +08:00
}
t/clang/expr-traits Patch authored by David Abrahams. These two expression traits (__is_lvalue_expr, __is_rvalue_expr) are used for parsing code that employs certain features of the Embarcadero C++ compiler. llvm-svn: 130122
2011-04-25 14:54:41 +08:00
/// ParseExpressionTrait - Parse built-in expression-trait
/// pseudo-functions like __is_lvalue_expr( xxx ).
///
/// primary-expression:
/// [Embarcadero] expression-trait '(' expression ')'
///
ExprResult Parser::ParseExpressionTrait() {
ExpressionTrait ET = ExpressionTraitFromTokKind(Tok.getKind());
SourceLocation Loc = ConsumeToken();
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
BalancedDelimiterTracker T(*this, tok::l_paren);
ExpectAndConsume: Diagnose errors automatically 1) Teach ExpectAndConsume() to emit expected and expected-after diagnostics using the generic diagnostic descriptions added in r197972, eliminating another set of trivial err_expected_* variations while maintaining existing behaviour. 2) Lift SkipUntil() recovery out of ExpectAndConsume(). The Expect/Consume family of functions are primitive parser operations that now have the well-defined property of operating on single tokens. Factoring out recovery exposes opportunities for more consistent and tailored error recover at the call sites instead of just relying on a bottled SkipUntil formula. llvm-svn: 198270
2014-01-01 11:08:43 +08:00
if (T.expectAndConsume())
t/clang/expr-traits Patch authored by David Abrahams. These two expression traits (__is_lvalue_expr, __is_rvalue_expr) are used for parsing code that employs certain features of the Embarcadero C++ compiler. llvm-svn: 130122
2011-04-25 14:54:41 +08:00
return ExprError();
ExprResult Expr = ParseExpression();
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
T.consumeClose();
t/clang/expr-traits Patch authored by David Abrahams. These two expression traits (__is_lvalue_expr, __is_rvalue_expr) are used for parsing code that employs certain features of the Embarcadero C++ compiler. llvm-svn: 130122
2011-04-25 14:54:41 +08:00
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
return Actions.ActOnExpressionTrait(ET, Loc, Expr.get(),
T.getCloseLocation());
t/clang/expr-traits Patch authored by David Abrahams. These two expression traits (__is_lvalue_expr, __is_rvalue_expr) are used for parsing code that employs certain features of the Embarcadero C++ compiler. llvm-svn: 130122
2011-04-25 14:54:41 +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,
PR19748: Make sure we don't lose colon protection after the parenthesized type-id in a cast-expression. llvm-svn: 208843
2014-05-15 10:43:47 +08:00
BalancedDelimiterTracker &Tracker,
ColonProtectionRAIIObject &ColonProt) {
Unify naming of LangOptions variable/get function across the Clang stack (Lex to AST). The member variable is always "LangOpts" and the member function is always "getLangOpts". Reviewed by Chris Lattner llvm-svn: 152536
2012-03-11 15:00:24 +08:00
assert(getLangOpts().CPlusPlus && "Should only be called for C++!");
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
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.
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
Tracker.consumeClose();
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 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
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.
PR19748: Make sure we don't lose colon protection after the parenthesized type-id in a cast-expression. llvm-svn: 208843
2014-05-15 10:43:47 +08:00
ColonProt.restore();
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
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,
[ARC] When casting from a pointer to an objective-c object with known ownership, if the cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type to the cast type: id x; (NSString**)&x; // Casting as (__strong NSString**). llvm-svn: 134275
2011-07-02 06:22:59 +08:00
// type-id has priority.
Avoid correcting unknown identifiers to types where types aren't allowed. Pass a typo correction callback object from ParseCastExpr to Sema::ActOnIdExpression to be a bit more selective about what kinds of corrections will be allowed for unknown identifiers. llvm-svn: 148973
2012-01-26 04:49:08 +08:00
IsTypeCast);
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) {
[ARC] When casting from a pointer to an objective-c object with known ownership, if the cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type to the cast type: id x; (NSString**)&x; // Casting as (__strong NSString**). llvm-svn: 134275
2011-07-02 06:22:59 +08:00
// Parse the type declarator.
DeclSpec DS(AttrFactory);
Declarator DeclaratorInfo(DS, Declarator::TypeNameContext);
PR19748: Make sure we don't lose colon protection after the parenthesized type-id in a cast-expression. llvm-svn: 208843
2014-05-15 10:43:47 +08:00
{
ColonProtectionRAIIObject InnerColonProtection(*this);
ParseSpecifierQualifierList(DS);
ParseDeclarator(DeclaratorInfo);
}
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 ')'.
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
Tracker.consumeClose();
PR19748: Make sure we don't lose colon protection after the parenthesized type-id in a cast-expression. llvm-svn: 208843
2014-05-15 10:43:47 +08:00
ColonProt.restore();
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 (ParseAs == CompoundLiteral) {
ExprType = CompoundLiteral;
Replace completely bogus ambiguous-compound-literal-in-C++ code with something that isn't always wrong. llvm-svn: 208844
2014-05-15 10:51:15 +08:00
if (DeclaratorInfo.isInvalidType())
return ExprError();
TypeResult Ty = Actions.ActOnTypeName(getCurScope(), DeclaratorInfo);
PR19748: Make sure we don't lose colon protection after the parenthesized type-id in a cast-expression. llvm-svn: 208843
2014-05-15 10:43:47 +08:00
return ParseCompoundLiteralExpression(Ty.get(),
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
Tracker.getOpenLocation(),
Tracker.getCloseLocation());
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
}
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);
[ARC] When casting from a pointer to an objective-c object with known ownership, if the cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type to the cast type: id x; (NSString**)&x; // Casting as (__strong NSString**). llvm-svn: 134275
2011-07-02 06:22:59 +08:00
if (DeclaratorInfo.isInvalidType())
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
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
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())
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
Result = Actions.ActOnCastExpr(getCurScope(), Tracker.getOpenLocation(),
DeclaratorInfo, CastTy,
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Tracker.getCloseLocation(), Result.get());
Rip out remnants of move semantic emulation and smart pointers in Sema. These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
2012-08-24 05:35:17 +08:00
return Result;
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 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))
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
Result = Actions.ActOnParenExpr(Tracker.getOpenLocation(),
Refactoring. Remove release and take methods from ActionResult. Rename takeAs to getAs. llvm-svn: 209800
2014-05-29 18:55:11 +08:00
Tok.getLocation(), Result.get());
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()) {
Replaced bool parameters in SkipUntil function with single bit-based parameter. llvm-svn: 194994
2013-11-18 16:17:37 +08:00
SkipUntil(tok::r_paren, StopAtSemi);
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 ExprError();
}
Remove tabs, and whitespace cleanups. llvm-svn: 81346
2009-09-09 23:08:12 +08:00
Introduce BalancedDelimiterTracker, to better track open/close delimiter pairs and detect when we exceed the implementation limit for nesting depth, from Aaron Ballman! llvm-svn: 141782
2011-10-13 00:37:45 +08:00
Tracker.consumeClose();
Rip out remnants of move semantic emulation and smart pointers in Sema. These were nops for quite a while and only lead to confusion. ASTMultiPtr now behaves like a proper dumb array reference. llvm-svn: 162475
2012-08-24 05:35:17 +08:00
return Result;
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
}