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

3289 lines
119 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++.
//
//===----------------------------------------------------------------------===//
Publish RAIIObjectsForParser.h for external usage. Some clients (eg the cling interpreter) need to recover their parser from errors. Patch by Axel Naumann (D31190)! llvm-svn: 298606
2017-03-23 23:11:07 +08:00
#include "clang/Parse/Parser.h"
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"
[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"
Publish RAIIObjectsForParser.h for external usage. Some clients (eg the cling interpreter) need to recover their parser from errors. Patch by Axel Naumann (D31190)! llvm-svn: 298606
2017-03-23 23:11:07 +08:00
#include "clang/Parse/RAIIObjectsForParser.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
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// 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
///
Implement DR 373 "Lookup on namespace qualified name in using-directive" Summary: 3.4.6 [basic.lookup.udir] paragraph 1: In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered. Reviewers: rsmith, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30848 llvm-svn: 298126
2017-03-18 05:41:20 +08:00
/// \param OnlyNamespace If true, only considers namespaces in lookup.
///
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,
Implement DR 373 "Lookup on namespace qualified name in using-directive" Summary: 3.4.6 [basic.lookup.udir] paragraph 1: In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered. Reviewers: rsmith, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30848 llvm-svn: 298126
2017-03-18 05:41:20 +08:00
IdentifierInfo **LastII,
bool OnlyNamespace) {
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");
For variables with dependent type, don't crash on `var->::new` or `var->__super` ParsePostfixExpressionSuffix() for '->' (or '.') postfixes first calls ActOnStartCXXMemberReference() to inform sema that a member reference is about to start, and that function lets the parser know if sema thinks that the base expression's type could allow a pseudo destructor from a semantic point of view (for example, if the the base expression has a dependent type). ParsePostfixExpressionSuffix() then calls ParseOptionalCXXScopeSpecifier() and passes MayBePseudoDestructor on to that function, expecting the function to set it to false if a pseudo destructor is impossible from a syntactic point of view (due to a lack of '~' sigil). However, ParseOptionalCXXScopeSpecifier() had early-outs for ::new and __super, so MayBePseudoDestructor stayed true, so we tried to parse a pseudo dtor, and then became confused since we couldn't find a '~'. Move the snippet in ParseOptionalCXXScopeSpecifier() that sets MayBePseudoDestructor to false above the early exits. Parts of this found by SLi's bot. llvm-svn: 229449
2015-02-17 06:32:46 +08:00
assert(!MayBePseudoDestructor && "unexpected annot_cxxscope");
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);
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
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;
}
For variables with dependent type, don't crash on `var->::new` or `var->__super` ParsePostfixExpressionSuffix() for '->' (or '.') postfixes first calls ActOnStartCXXMemberReference() to inform sema that a member reference is about to start, and that function lets the parser know if sema thinks that the base expression's type could allow a pseudo destructor from a semantic point of view (for example, if the the base expression has a dependent type). ParsePostfixExpressionSuffix() then calls ParseOptionalCXXScopeSpecifier() and passes MayBePseudoDestructor on to that function, expecting the function to set it to false if a pseudo destructor is impossible from a syntactic point of view (due to a lack of '~' sigil). However, ParseOptionalCXXScopeSpecifier() had early-outs for ::new and __super, so MayBePseudoDestructor stayed true, so we tried to parse a pseudo dtor, and then became confused since we couldn't find a '~'. Move the snippet in ParseOptionalCXXScopeSpecifier() that sets MayBePseudoDestructor to false above the early exits. Parts of this found by SLi's bot. llvm-svn: 229449
2015-02-17 06:32:46 +08:00
// Has to happen before any "return false"s in this function.
bool CheckForDestructor = false;
if (MayBePseudoDestructor && *MayBePseudoDestructor) {
CheckForDestructor = true;
*MayBePseudoDestructor = false;
}
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
Parse: Ignore '::' in 'struct :: {' Let's pretend that we didn't see the '::' instead of go on believing that we've got some anonymous, but globally qualified, struct. llvm-svn: 224945
2014-12-30 03:19:18 +08:00
if (NextKind == tok::l_brace) {
// It is invalid to have :: {, consume the scope qualifier and pretend
// like we never saw it.
Diag(ConsumeToken(), diag::err_expected) << tok::identifier;
} else {
// '::' - Global scope qualifier.
if (Actions.ActOnCXXGlobalScopeSpecifier(ConsumeToken(), SS))
return true;
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);
}
PR20991: ::decltype is not valid. llvm-svn: 219043
2014-10-04 09:57:39 +08:00
if (!HasScopeSpecifier &&
[clang] Refactoring of conditions so they use isOneOf() instead of multiple is(). llvm-svn: 240008
2015-06-18 18:59:26 +08:00
Tok.isOneOf(tok::kw_decltype, 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;
Don't crash on 'decltype(auto)::'. Rather than treating it as a meaningless nested-name-specifier (as the standard appears to require), treat it as the type specifier 'decltype(auto)' followed by a nested-name-specifier starting with '::'. llvm-svn: 294506
2017-02-09 03:58:48 +08:00
// Work around a standard defect: 'decltype(auto)::' is not a
// nested-name-specifier.
if (DS.getTypeSpecType() == DeclSpec::TST_decltype_auto ||
!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.
OpaquePtr: Use nullptr construction for ParsedType OpaquePtr typedef llvm-svn: 257958
2016-01-16 07:43:34 +08:00
ObjectType = nullptr;
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
Fix comment typo llvm-svn: 317216
2017-11-03 00:37:00 +08:00
// 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
[NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum UnqualifiedIdKind. llvm-svn: 321574
2017-12-30 12:15:27 +08:00
if (TemplateName.getKind() != UnqualifiedIdKind::IK_OperatorFunctionId &&
TemplateName.getKind() != UnqualifiedIdKind::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;
Finish implementation of C++ DR1310 (http://wg21.link/cwg1310). Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
2017-01-20 08:20:39 +08:00
if (TemplateNameKind TNK = Actions.ActOnDependentTemplateName(
getCurScope(), SS, TemplateKWLoc, TemplateName, ObjectType,
EnteringContext, Template, /*AllowInjectedClassName*/ true)) {
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, 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.
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
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();
Pass information in a record instead of stack. NFC Functions of Sema that work with building of nested name specifiers have too many parameters (BuildCXXNestedNameSpecifier already expects 10 arguments). With this change the information about identifier and its context is packed into a structure, which is then passes to the semantic functions. llvm-svn: 277976
2016-08-08 12:02:15 +08:00
Sema::NestedNameSpecInfo IdInfo(&II, Tok.getLocation(), Next.getLocation(),
ObjectType);
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) {
Pass information in a record instead of stack. NFC Functions of Sema that work with building of nested name specifiers have too many parameters (BuildCXXNestedNameSpecifier already expects 10 arguments). With this change the information about identifier and its context is packed into a structure, which is then passes to the semantic functions. llvm-svn: 277976
2016-08-08 12:02:15 +08:00
if (Actions.IsInvalidUnlessNestedName(getCurScope(), SS, IdInfo,
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
}
Parse: Recover more gracefully from extra :: tokens before a { Instead of crashing, recover by eating the extra trailing scope qualifier. This means we will treat 'struct A:: {' as 'struct A {'. llvm-svn: 224966
2014-12-30 07:12:23 +08:00
if (Next.is(tok::coloncolon) && GetLookAheadToken(2).is(tok::l_brace)) {
// It is invalid to have :: {, consume the scope qualifier and pretend
// like we never saw it.
Token Identifier = Tok; // Stash away the identifier.
ConsumeToken(); // Eat the identifier, current token is now '::'.
Fix build breakage That's what I get for last second changes... llvm-svn: 224967
2014-12-30 07:24:27 +08:00
Diag(PP.getLocForEndOfToken(ConsumeToken()), diag::err_expected)
<< tok::identifier;
Parse: Recover more gracefully from extra :: tokens before a { Instead of crashing, recover by eating the extra trailing scope qualifier. This means we will treat 'struct A:: {' as 'struct A {'. llvm-svn: 224966
2014-12-30 07:12:23 +08:00
UnconsumeToken(Identifier); // Stick the identifier back.
Next = NextToken(); // Point Next at the '{' token.
}
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) &&
Pass information in a record instead of stack. NFC Functions of Sema that work with building of nested name specifiers have too many parameters (BuildCXXNestedNameSpecifier already expects 10 arguments). With this change the information about identifier and its context is packed into a structure, which is then passes to the semantic functions. llvm-svn: 277976
2016-08-08 12:02:15 +08:00
!Actions.isNonTypeNestedNameSpecifier(getCurScope(), SS, IdInfo)) {
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();
[clang] Refactoring of conditions so they use isOneOf() instead of multiple is(). llvm-svn: 240008
2015-06-18 18:59:26 +08:00
assert(Tok.isOneOf(tok::coloncolon, tok::colon) &&
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
"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
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;
Implement DR 373 "Lookup on namespace qualified name in using-directive" Summary: 3.4.6 [basic.lookup.udir] paragraph 1: In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered. Reviewers: rsmith, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30848 llvm-svn: 298126
2017-03-18 05:41:20 +08:00
if (Actions.ActOnCXXNestedNameSpecifier(
getCurScope(), IdInfo, EnteringContext, SS, false,
CorrectionFlagPtr, OnlyNamespace)) {
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
// 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 ");
Finish implementation of C++ DR1310 (http://wg21.link/cwg1310). Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
2017-01-20 08:20:39 +08:00
if (TemplateNameKind TNK = Actions.ActOnDependentTemplateName(
Improve diagnostics and error recovery for template name lookup. For 'x::template y', consistently give a "no member named 'y' in 'x'" diagnostic if there is no such member, and give a 'template keyword not followed by a template' name error if there is such a member but it's not a template. In the latter case, add a note pointing at the non-template. Don't suggest inserting a 'template' keyword in 'X::Y<' if X is dependent if the lookup of X::Y was actually not a dependent lookup and found only non-templates. llvm-svn: 332076
2018-05-11 10:43:08 +08:00
getCurScope(), SS, Tok.getLocation(), TemplateName, ObjectType,
Finish implementation of C++ DR1310 (http://wg21.link/cwg1310). Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
2017-01-20 08:20:39 +08:00
EnteringContext, Template, /*AllowInjectedClassName*/ 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
// 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
}
Wire up delayed typo correction to DiagnoseEmptyLookup and set up Sema::ActOnIdExpression to use the new functionality. Among other things, this allows recovery in several cases where it wasn't possible before (e.g. correcting a mistyped static_cast<>). llvm-svn: 222464
2014-11-21 06:06:40 +08:00
ExprResult Parser::tryParseCXXIdExpression(CXXScopeSpec &SS, bool isAddressOfOperand,
Token &Replacement) {
SourceLocation TemplateKWLoc;
UnqualifiedId Name;
if (ParseUnqualifiedId(SS,
/*EnteringContext=*/false,
/*AllowDestructorName=*/false,
/*AllowConstructorName=*/false,
P0091R3: Implement basic parsing support for C++17 deduction-guides. We model deduction-guides as functions with a new kind of name that identifies the template whose deduction they guide; the bulk of this patch is adding the new name kind. This gives us a clean way to attach an extensible list of guides to a class template in a way that doesn't require any special handling in AST files etc (and we're going to need these functions we come to performing deduction). llvm-svn: 294266
2017-02-07 09:37:30 +08:00
/*AllowDeductionGuide=*/false,
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
/*ObjectType=*/nullptr, &TemplateKWLoc, Name))
Wire up delayed typo correction to DiagnoseEmptyLookup and set up Sema::ActOnIdExpression to use the new functionality. Among other things, this allows recovery in several cases where it wasn't possible before (e.g. correcting a mistyped static_cast<>). llvm-svn: 222464
2014-11-21 06:06:40 +08:00
return ExprError();
// This is only the direct operand of an & operator if it is not
// followed by a postfix-expression suffix.
if (isAddressOfOperand && isPostfixExpressionSuffixStart())
isAddressOfOperand = false;
return Actions.ActOnIdExpression(getCurScope(), SS, TemplateKWLoc, Name,
Tok.is(tok::l_paren), isAddressOfOperand,
nullptr, /*IsInlineAsmIdentifier=*/false,
&Replacement);
}
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;
OpaquePtr: Use nullptr construction for ParsedType OpaquePtr typedef llvm-svn: 257958
2016-01-16 07:43:34 +08:00
ParseOptionalCXXScopeSpecifier(SS, nullptr, /*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
Wire up delayed typo correction to DiagnoseEmptyLookup and set up Sema::ActOnIdExpression to use the new functionality. Among other things, this allows recovery in several cases where it wasn't possible before (e.g. correcting a mistyped static_cast<>). llvm-svn: 222464
2014-11-21 06:06:40 +08:00
Token Replacement;
Wrap to 80 columns. No behavior change. llvm-svn: 229282
2015-02-15 14:15:40 +08:00
ExprResult Result =
tryParseCXXIdExpression(SS, isAddressOfOperand, Replacement);
Wire up delayed typo correction to DiagnoseEmptyLookup and set up Sema::ActOnIdExpression to use the new functionality. Among other things, this allows recovery in several cases where it wasn't possible before (e.g. correcting a mistyped static_cast<>). llvm-svn: 222464
2014-11-21 06:06:40 +08:00
if (Result.isUnset()) {
// If the ExprResult is valid but null, then typo correction suggested a
// keyword replacement that needs to be reparsed.
UnconsumeToken(Replacement);
Result = tryParseCXXIdExpression(SS, isAddressOfOperand, Replacement);
}
assert(!Result.isUnset() && "Typo correction suggested a keyword replacement "
"for a previous keyword suggestion");
return Result;
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());
Parse: It's cleaner to handle cxx_defaultarg_end in SkipUntil directly llvm-svn: 225616
2015-01-12 11:36: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.");
[Parser] Fix look ahead after EOF while parsing objc message and lambdas If a closing ')' isn't found for a macro instantiation inside a '[', the next token is EOF, this leads to crashes if we try to look ahead of that. This could be triggered whenever trying to parse lambdas or objs message expressions. Differential Revision: http://reviews.llvm.org/D20451 rdar://problem/25662647 llvm-svn: 271314
2016-06-01 02:46:31 +08:00
const Token Next = NextToken();
if (Next.is(tok::eof)) // Nothing else to lookup here...
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
[Parser] Fix look ahead after EOF while parsing objc message and lambdas If a closing ')' isn't found for a macro instantiation inside a '[', the next token is EOF, this leads to crashes if we try to look ahead of that. This could be triggered whenever trying to parse lambdas or objs message expressions. Differential Revision: http://reviews.llvm.org/D20451 rdar://problem/25662647 llvm-svn: 271314
2016-06-01 02:46:31 +08:00
const Token After = GetLookAheadToken(2);
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 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);
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parse a lambda introducer.
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
/// \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
Remove repeated word in comment (NFC) llvm-svn: 291667
2017-01-11 19:23:22 +08:00
/// the diagnostic is that of the current token.
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
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;
N3922: direct-list-initialization of an auto-typed variable no longer deduces a std::initializer_list<T> type. Instead, the list must contain a single element and the type is deduced from that. In Clang 3.7, we warned by default on all the cases that would change meaning due to this change. In Clang 3.8, we will support only the new rules -- per the request in N3922, this change is applied as a Defect Report against earlier versions of the C++ standard. This change is not entirely trivial, because for lambda init-captures we previously did not track the difference between direct-list-initialization and copy-list-initialization. The difference was not previously observable, because the two forms of initialization always did the same thing (the elements of the initializer list were always copy-initialized regardless of the initialization style used for the init-capture). llvm-svn: 252688
2015-11-11 09:36:17 +08:00
LambdaCaptureInitKind InitKind = LambdaCaptureInitKind::NoInit;
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 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;
[Cxx1z] Implement Lambda Capture of *this by Value as [=,*this] (P0018R3) Implement lambda capture of *this by copy. For e.g.: struct A { int d = 10; auto foo() { return [*this] (auto a) mutable { d+=a; return d; }; } }; auto L = A{}.foo(); // A{}'s lifetime is gone. // Below is still ok, because *this was captured by value. assert(L(10) == 20); assert(L(100) == 120); If the capture was implicit, or [this] (i.e. *this was captured by reference), this code would be otherwise undefined. Implementation Strategy: - amend the parser to accept *this in the lambda introducer - add a new king of capture LCK_StarThis - teach Sema::CheckCXXThisCapture to handle by copy captures of the enclosing object (i.e. *this) - when CheckCXXThisCapture does capture by copy, the corresponding initializer expression for the closure's data member direct-initializes it thus making a copy of '*this'. - in codegen, when assigning to CXXThisValue, if *this was captured by copy, make sure it points to the corresponding field member, and not, unlike when captured by reference, what the field member points to. - mark feature as implemented in svn Much gratitude to Richard Smith for his carefully illuminating reviews! llvm-svn: 263921
2016-03-21 17:25:37 +08:00
if (Tok.is(tok::star)) {
Loc = ConsumeToken();
if (Tok.is(tok::kw_this)) {
ConsumeToken();
Kind = LCK_StarThis;
} else {
return DiagResult(diag::err_expected_star_this_capture);
}
} else if (Tok.is(tok::kw_this)) {
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
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();
N3922: direct-list-initialization of an auto-typed variable no longer deduces a std::initializer_list<T> type. Instead, the list must contain a single element and the type is deduced from that. In Clang 3.7, we warned by default on all the cases that would change meaning due to this change. In Clang 3.8, we will support only the new rules -- per the request in N3922, this change is applied as a Defect Report against earlier versions of the C++ standard. This change is not entirely trivial, because for lambda init-captures we previously did not track the difference between direct-list-initialization and copy-list-initialization. The difference was not previously observable, because the two forms of initialization always did the same thing (the elements of the initializer list were always copy-initialized regardless of the initialization style used for the init-capture). llvm-svn: 252688
2015-11-11 09:36:17 +08:00
InitKind = LambdaCaptureInitKind::DirectInit;
C++1y n3648: parse and reject init-captures for now. llvm-svn: 181553
2013-05-10 05:36:41 +08:00
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);
}
[clang] Refactoring of conditions so they use isOneOf() instead of multiple is(). llvm-svn: 240008
2015-06-18 18:59:26 +08:00
} else if (Tok.isOneOf(tok::l_brace, 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.
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext EC(
Actions, Sema::ExpressionEvaluationContext::PotentiallyEvaluated);
N3922: direct-list-initialization of an auto-typed variable no longer deduces a std::initializer_list<T> type. Instead, the list must contain a single element and the type is deduced from that. In Clang 3.7, we warned by default on all the cases that would change meaning due to this change. In Clang 3.8, we will support only the new rules -- per the request in N3922, this change is applied as a Defect Report against earlier versions of the C++ standard. This change is not entirely trivial, because for lambda init-captures we previously did not track the difference between direct-list-initialization and copy-list-initialization. The difference was not previously observable, because the two forms of initialization always did the same thing (the elements of the initializer list were always copy-initialized regardless of the initialization style used for the init-capture). llvm-svn: 252688
2015-11-11 09:36:17 +08:00
if (TryConsumeToken(tok::equal))
InitKind = LambdaCaptureInitKind::CopyInit;
else
InitKind = LambdaCaptureInitKind::ListInit;
Add a warning for direct-list-initialization of a variable with a deduced type (or of a lambda init-capture, which is sort-of such a variable). The semantics of such constructs will change when we implement N3922, so we intend to warn on this in Clang 3.6 then change the semantics in Clang 3.7. llvm-svn: 228792
2015-02-11 10:41:33 +08:00
if (!SkippedInits) {
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
Init = ParseInitializer();
Add a warning for direct-list-initialization of a variable with a deduced type (or of a lambda init-capture, which is sort-of such a variable). The semantics of such constructs will change when we implement N3922, so we intend to warn on this in Clang 3.6 then change the semantics in Clang 3.7. llvm-svn: 228792
2015-02-11 10:41:33 +08:00
} else if (Tok.is(tok::l_brace)) {
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
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();
[Parser] Correct typo after lambda capture initializer is parsed. This patch fixes an assertion that is triggered when RecordLayoutBuilder tries to compute the size of a field (for capture "name" in the test case) whose type hasn't been deduced. The patch fixes the bug by correcting the typo of the capture initializer after the initializer is parsed and before setting the expression for the annotation token. Fixes PR30566. rdar://problem/23380132 Differential Revision: https://reviews.llvm.org/D25206 llvm-svn: 290156
2016-12-20 10:11:29 +08:00
if (!Init.isInvalid())
Init = Actions.CorrectDelayedTyposInExpr(Init.get());
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 (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.
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
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
}
}
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;
// }
// };
P0217R3: Parsing support and framework for AST representation of C++1z decomposition declarations. There are a couple of things in the wording that seem strange here: decomposition declarations are permitted at namespace scope (which we partially support here) and they are permitted as the declaration in a template (which we reject). llvm-svn: 276492
2016-07-23 07:36:59 +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 x was not const, the second use would require 'L' to capture, and
// that would be an error.
N3922: direct-list-initialization of an auto-typed variable no longer deduces a std::initializer_list<T> type. Instead, the list must contain a single element and the type is deduced from that. In Clang 3.7, we warned by default on all the cases that would change meaning due to this change. In Clang 3.8, we will support only the new rules -- per the request in N3922, this change is applied as a Defect Report against earlier versions of the C++ standard. This change is not entirely trivial, because for lambda init-captures we previously did not track the difference between direct-list-initialization and copy-list-initialization. The difference was not previously observable, because the two forms of initialization always did the same thing (the elements of the initializer list were always copy-initialized regardless of the initialization style used for the init-capture). llvm-svn: 252688
2015-11-11 09:36:17 +08:00
ParsedType InitCaptureType;
[Parser] Correct initalizer typos before lambda capture type is deduced. This is the same assertion as in https://reviews.llvm.org/D25206 that is triggered when RecordLayoutBuilder tries to compute the size of a field (for capture "typo_boo" in the test case) whose type hasn't been deduced. The fix is to add CorrectDelayedTyposInExpr call to the cases when we aren't disambiguating between an Obj-C message send and a lambda expression. rdar://problem/31760839 Reviewers: rsmith, ahatanak Reviewed By: arphaman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D36853 llvm-svn: 311480
2017-08-23 01:55:19 +08:00
if (!Init.isInvalid())
Init = Actions.CorrectDelayedTyposInExpr(Init.get());
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 (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.
N3922: direct-list-initialization of an auto-typed variable no longer deduces a std::initializer_list<T> type. Instead, the list must contain a single element and the type is deduced from that. In Clang 3.7, we warned by default on all the cases that would change meaning due to this change. In Clang 3.8, we will support only the new rules -- per the request in N3922, this change is applied as a Defect Report against earlier versions of the C++ standard. This change is not entirely trivial, because for lambda init-captures we previously did not track the difference between direct-list-initialization and copy-list-initialization. The difference was not previously observable, because the two forms of initialization always did the same thing (the elements of the initializer list were always copy-initialized regardless of the initialization style used for the init-capture). llvm-svn: 252688
2015-11-11 09:36:17 +08:00
InitCaptureType = Actions.actOnLambdaInitCaptureInitialization(
Loc, Kind == LCK_ByRef, Id, InitKind, InitExpr);
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
Init = InitExpr;
}
N3922: direct-list-initialization of an auto-typed variable no longer deduces a std::initializer_list<T> type. Instead, the list must contain a single element and the type is deduced from that. In Clang 3.7, we warned by default on all the cases that would change meaning due to this change. In Clang 3.8, we will support only the new rules -- per the request in N3922, this change is applied as a Defect Report against earlier versions of the C++ standard. This change is not entirely trivial, because for lambda init-captures we previously did not track the difference between direct-list-initialization and copy-list-initialization. The difference was not previously observable, because the two forms of initialization always did the same thing (the elements of the initializer list were always copy-initialized regardless of the initialization style used for the init-capture). llvm-svn: 252688
2015-11-11 09:36:17 +08:00
Intro.addCapture(Kind, Loc, Id, EllipsisLoc, InitKind, Init,
InitCaptureType);
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) {
[Parser] Fix TryParseLambdaIntroducer() error handling rdar://35066196 Differential Revision: https://reviews.llvm.org/D39419 llvm-svn: 317493
2017-11-07 01:42:17 +08:00
{
bool SkippedInits = false;
TentativeParsingAction PA1(*this);
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
[Parser] Fix TryParseLambdaIntroducer() error handling rdar://35066196 Differential Revision: https://reviews.llvm.org/D39419 llvm-svn: 317493
2017-11-07 01:42:17 +08:00
if (ParseLambdaIntroducer(Intro, &SkippedInits)) {
PA1.Revert();
return true;
}
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
[Parser] Fix TryParseLambdaIntroducer() error handling rdar://35066196 Differential Revision: https://reviews.llvm.org/D39419 llvm-svn: 317493
2017-11-07 01:42:17 +08:00
if (!SkippedInits) {
PA1.Commit();
return false;
}
PA1.Revert();
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
}
[Parser] Fix TryParseLambdaIntroducer() error handling rdar://35066196 Differential Revision: https://reviews.llvm.org/D39419 llvm-svn: 317493
2017-11-07 01:42:17 +08:00
// Try to parse it again, but this time parse the init-captures too.
Intro = LambdaIntroducer();
TentativeParsingAction PA2(*this);
if (!ParseLambdaIntroducer(Intro)) {
PA2.Commit();
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
return false;
}
[Parser] Fix TryParseLambdaIntroducer() error handling rdar://35066196 Differential Revision: https://reviews.llvm.org/D39419 llvm-svn: 317493
2017-11-07 01:42:17 +08:00
PA2.Revert();
return true;
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
}
[Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. llvm-svn: 264513
2016-03-27 00:11:37 +08:00
static void
tryConsumeMutableOrConstexprToken(Parser &P, SourceLocation &MutableLoc,
SourceLocation &ConstexprLoc,
SourceLocation &DeclEndLoc) {
assert(MutableLoc.isInvalid());
assert(ConstexprLoc.isInvalid());
// Consume constexpr-opt mutable-opt in any sequence, and set the DeclEndLoc
// to the final of those locations. Emit an error if we have multiple
// copies of those keywords and recover.
while (true) {
switch (P.getCurToken().getKind()) {
case tok::kw_mutable: {
if (MutableLoc.isValid()) {
P.Diag(P.getCurToken().getLocation(),
diag::err_lambda_decl_specifier_repeated)
<< 0 << FixItHint::CreateRemoval(P.getCurToken().getLocation());
}
MutableLoc = P.ConsumeToken();
DeclEndLoc = MutableLoc;
break /*switch*/;
}
case tok::kw_constexpr:
if (ConstexprLoc.isValid()) {
P.Diag(P.getCurToken().getLocation(),
diag::err_lambda_decl_specifier_repeated)
<< 1 << FixItHint::CreateRemoval(P.getCurToken().getLocation());
}
ConstexprLoc = P.ConsumeToken();
DeclEndLoc = ConstexprLoc;
break /*switch*/;
default:
return;
}
}
}
static void
addConstexprToLambdaDeclSpecifier(Parser &P, SourceLocation ConstexprLoc,
DeclSpec &DS) {
if (ConstexprLoc.isValid()) {
Now that C++17 is official (https://www.iso.org/standard/68564.html), start changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
2017-12-05 04:27:34 +08:00
P.Diag(ConstexprLoc, !P.getLangOpts().CPlusPlus17
Rename cxx1z -> cxx17 across all diagnostic IDs. llvm-svn: 310805
2017-08-14 07:37:29 +08:00
? diag::ext_constexpr_on_lambda_cxx17
[Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. llvm-svn: 264513
2016-03-27 00:11:37 +08:00
: diag::warn_cxx14_compat_constexpr_on_lambda);
const char *PrevSpec = nullptr;
unsigned DiagID = 0;
DS.SetConstexprSpec(ConstexprLoc, PrevSpec, DiagID);
assert(PrevSpec == nullptr && DiagID == 0 &&
"Constexpr cannot have been set previously!");
}
}
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
/// 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);
[NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum. Note, we don't do any bitwise manipulations when using them. llvm-svn: 321546
2017-12-29 13:41:00 +08:00
Declarator D(DS, DeclaratorContext::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);
[CUDA] Handle attributes on CUDA lambdas appearing between [...] and (...). Summary: This is ugh, but it makes us compatible with NVCC. Fixes bug 26341. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25103 llvm-svn: 282879
2016-10-01 01:14:48 +08:00
Actions.PushLambdaScope();
ParsedAttributes Attr(AttrFactory);
SourceLocation DeclLoc = Tok.getLocation();
if (getLangOpts().CUDA) {
// In CUDA code, GNU attributes are allowed to appear immediately after the
// "[...]", even if there is no "(...)" before the lambda body.
[CUDA] Fix up MaybeParseGNUAttributes call used for out-of-place attributes on CUDA lambdas. Summary: There's an overload that we can use to make this a bit cleaner. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25114 llvm-svn: 282910
2016-10-01 03:55:48 +08:00
MaybeParseGNUAttributes(D);
[CUDA] Handle attributes on CUDA lambdas appearing between [...] and (...). Summary: This is ugh, but it makes us compatible with NVCC. Fixes bug 26341. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25103 llvm-svn: 282879
2016-10-01 01:14:48 +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
[CUDA] Emit a warning if a CUDA host/device/global attribute is placed after '(...)'. Summary: This is probably the sane place for the attribute to go, but nvcc specifically rejects it. Other GNU-style attributes are allowed in this position (although judging from the warning it emits for host/device/global, those attributes are applied to the lambda's anonymous struct, not to the function itself). It would be nice to have a FixIt message here, but doing so, or even just getting the correct range for the attribute, including its '((' and '))'s, is apparently Hard. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25115 llvm-svn: 282911
2016-10-01 03:55:55 +08:00
// Helper to emit a warning if we see a CUDA host/device/global attribute
// after '(...)'. nvcc doesn't accept this.
auto WarnIfHasCUDATargetAttr = [&] {
if (getLangOpts().CUDA)
for (auto *A = Attr.getList(); A != nullptr; A = A->getNext())
if (A->getKind() == AttributeList::AT_CUDADevice ||
A->getKind() == AttributeList::AT_CUDAHost ||
A->getKind() == AttributeList::AT_CUDAGlobal)
Diag(A->getLoc(), diag::warn_cuda_attr_lambda_position)
<< A->getName()->getName();
};
Parse: Don't crash when trailing return type is missing Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo. Don't let the AST contain the malformed lambda. This fixes PR22122. llvm-svn: 225505
2015-01-09 13:10:55 +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::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);
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.
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();
[CUDA] Fix up MaybeParseGNUAttributes call used for out-of-place attributes on CUDA lambdas. Summary: There's an overload that we can use to make this a bit cleaner. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25114 llvm-svn: 282910
2016-10-01 03:55:48 +08:00
SourceLocation 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);
Parse: Handle __declspec in a lambda definition llvm-svn: 228121
2015-02-04 16:22:46 +08:00
// MSVC-style attributes must be parsed before the mutable specifier to be
// compatible with MSVC.
Refactored some common functionality into MaybeParseMicrosoftDeclSpecs; NFC. llvm-svn: 237835
2015-05-21 04:58:33 +08:00
MaybeParseMicrosoftDeclSpecs(Attr, &DeclEndLoc);
Parse: Handle __declspec in a lambda definition llvm-svn: 228121
2015-02-04 16:22:46 +08:00
[Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. llvm-svn: 264513
2016-03-27 00:11:37 +08:00
// Parse mutable-opt and/or constexpr-opt, and update the 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
SourceLocation MutableLoc;
[Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. llvm-svn: 264513
2016-03-27 00:11:37 +08:00
SourceLocation ConstexprLoc;
tryConsumeMutableOrConstexprToken(*this, MutableLoc, ConstexprLoc,
DeclEndLoc);
addConstexprToLambdaDeclSpecifier(*this, ConstexprLoc, DS);
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 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;
PR21437, final part of DR1330: delay-parsing of exception-specifications. This is a re-commit of Doug's r154844 (modernized and updated to fit into current Clang). llvm-svn: 221918
2014-11-14 04:01:57 +08:00
CachedTokens *ExceptionSpecTokens;
ESpecType = tryParseExceptionSpecification(/*Delayed=*/false,
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,
PR21437, final part of DR1330: delay-parsing of exception-specifications. This is a re-commit of Doug's r154844 (modernized and updated to fit into current Clang). llvm-svn: 221918
2014-11-14 04:01:57 +08:00
NoexceptExpr,
ExceptionSpecTokens);
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 (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;
Add missing direct-init / parameter-declaration-clause disambiguation when parsing a trailing-return-type of a (function pointer) variable declaration. llvm-svn: 324151
2018-02-03 06:24:54 +08:00
TrailingReturnType =
ParseTrailingReturnType(Range, /*MayBeFollowedByDirectInit*/ 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
if (Range.getEnd().isValid())
DeclEndLoc = Range.getEnd();
}
PrototypeScope.Exit();
[CUDA] Emit a warning if a CUDA host/device/global attribute is placed after '(...)'. Summary: This is probably the sane place for the attribute to go, but nvcc specifically rejects it. Other GNU-style attributes are allowed in this position (although judging from the warning it emits for host/device/global, those attributes are applied to the lambda's anonymous struct, not to the function itself). It would be nice to have a FixIt message here, but doing so, or even just getting the correct range for the attribute, including its '((' and '))'s, is apparently Hard. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25115 llvm-svn: 282911
2016-10-01 03:55:55 +08:00
WarnIfHasCUDATargetAttr();
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,
Modify DeclaratorChuck::getFunction to be passed an Exception Specification SourceRange Summary: - Store the exception specification range's begin and end SourceLocation in DeclaratorChuck::FunctionTypeInfo. These SourceLocations can be used in a FixItHint Range. - Add diagnostic; function concept having an exception specification. Reviewers: hubert.reinterpretcast, fraggamuffin, faisalv, aaron.ballman, rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11789 llvm-svn: 246005
2015-08-26 12:19:36 +08:00
ESpecType, ESpecRange,
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
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,
PR21437, final part of DR1330: delay-parsing of exception-specifications. This is a re-commit of Doug's r154844 (modernized and updated to fit into current Clang). llvm-svn: 221918
2014-11-14 04:01:57 +08:00
/*ExceptionSpecTokens*/nullptr,
Store decls in prototypes on the declarator instead of in the AST This saves two pointers from FunctionDecl that were being used for some rare and questionable C-only functionality. The DeclsInPrototypeScope ArrayRef was added in r151712 in order to parse this kind of C code: enum e {x, y}; int f(enum {y, x} n) { return x; // should return 1, not 0 } The challenge is that we parse 'int f(enum {y, x} n)' it its own function prototype scope that gets popped before we build the FunctionDecl for 'f'. The original change was doing two questionable things: 1. Saving all tag decls introduced in prototype scope on a TU-global Sema variable. This is problematic when you have cases like this, where 'x' and 'y' shouldn't be visible in 'f': void f(void (*fp)(enum { x, y } e)) { /* no x */ } This patch fixes that, so now 'f' can't see 'x', which is consistent with GCC. 2. Storing the decls in FunctionDecl in ActOnFunctionDeclarator so that they could be used in ActOnStartOfFunctionDef. This is just an inefficient way to move information around. The AST lives forever, but the list of non-parameter decls in prototype scope is short lived. Moving these things to the Declarator solves both of these issues. Reviewers: rsmith Subscribers: jmolloy, cfe-commits Differential Revision: https://reviews.llvm.org/D27279 llvm-svn: 289225
2016-12-10 01:14:05 +08:00
/*DeclsInPrototype=*/None,
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);
[Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. llvm-svn: 264513
2016-03-27 00:11:37 +08:00
} else if (Tok.isOneOf(tok::kw_mutable, tok::arrow, tok::kw___attribute,
tok::kw_constexpr) ||
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;
[Cxx1z-constexpr-lambda-P0170R1] Support parsing of constexpr specifier (and its inference) on lambda expressions Support the constexpr specifier on lambda expressions - and support its inference from the lambda call operator's body. i.e. auto L = [] () constexpr { return 5; }; static_assert(L() == 5); // OK auto Implicit = [] (auto a) { return a; }; static_assert(Implicit(5) == 5); We do not support evaluation of lambda's within constant expressions just yet. Implementation Strategy: - teach ParseLambdaExpressionAfterIntroducer to expect a constexpr specifier and mark the invented function call operator's declarator's decl-specifier with it; Have it emit fixits for multiple decl-specifiers (mutable or constexpr) in this location. - for cases where constexpr is not explicitly specified, have buildLambdaExpr check whether the invented function call operator satisfies the requirements of a constexpr function, by calling CheckConstexprFunctionDecl/Body. Much obliged to Richard Smith for his patience and his care, in ensuring the code is clang-worthy. llvm-svn: 264513
2016-03-27 00:11:37 +08:00
case tok::kw_constexpr: TokKind = 3; break;
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
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(), "() ");
[CUDA] Fix up MaybeParseGNUAttributes call used for out-of-place attributes on CUDA lambdas. Summary: There's an overload that we can use to make this a bit cleaner. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25114 llvm-svn: 282910
2016-10-01 03:55:48 +08:00
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.
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 (Tok.is(tok::arrow)) {
SourceRange Range;
Add missing direct-init / parameter-declaration-clause disambiguation when parsing a trailing-return-type of a (function pointer) variable declaration. llvm-svn: 324151
2018-02-03 06:24:54 +08:00
TrailingReturnType =
ParseTrailingReturnType(Range, /*MayBeFollowedByDirectInit*/ false);
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())
Parse: Don't crash when trailing return type is missing Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo. Don't let the AST contain the malformed lambda. This fixes PR22122. llvm-svn: 225505
2015-01-09 13:10:55 +08:00
DeclEndLoc = Range.getEnd();
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
}
[CUDA] Emit a warning if a CUDA host/device/global attribute is placed after '(...)'. Summary: This is probably the sane place for the attribute to go, but nvcc specifically rejects it. Other GNU-style attributes are allowed in this position (although judging from the warning it emits for host/device/global, those attributes are applied to the lambda's anonymous struct, not to the function itself). It would be nice to have a FixIt message here, but doing so, or even just getting the correct range for the attribute, including its '((' and '))'s, is apparently Hard. Reviewers: rnk Subscribers: cfe-commits, tra Differential Revision: https://reviews.llvm.org/D25115 llvm-svn: 282911
2016-10-01 03:55:55 +08:00
WarnIfHasCUDATargetAttr();
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,
Modify DeclaratorChuck::getFunction to be passed an Exception Specification SourceRange Summary: - Store the exception specification range's begin and end SourceLocation in DeclaratorChuck::FunctionTypeInfo. These SourceLocations can be used in a FixItHint Range. - Add diagnostic; function concept having an exception specification. Reviewers: hubert.reinterpretcast, fraggamuffin, faisalv, aaron.ballman, rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D11789 llvm-svn: 246005
2015-08-26 12:19:36 +08:00
/*ESpecRange=*/SourceRange(),
[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,
PR21437, final part of DR1330: delay-parsing of exception-specifications. This is a re-commit of Doug's r154844 (modernized and updated to fit into current Clang). llvm-svn: 221918
2014-11-14 04:01:57 +08:00
/*ExceptionSpecTokens=*/nullptr,
Store decls in prototypes on the declarator instead of in the AST This saves two pointers from FunctionDecl that were being used for some rare and questionable C-only functionality. The DeclsInPrototypeScope ArrayRef was added in r151712 in order to parse this kind of C code: enum e {x, y}; int f(enum {y, x} n) { return x; // should return 1, not 0 } The challenge is that we parse 'int f(enum {y, x} n)' it its own function prototype scope that gets popped before we build the FunctionDecl for 'f'. The original change was doing two questionable things: 1. Saving all tag decls introduced in prototype scope on a TU-global Sema variable. This is problematic when you have cases like this, where 'x' and 'y' shouldn't be visible in 'f': void f(void (*fp)(enum { x, y } e)) { /* no x */ } This patch fixes that, so now 'f' can't see 'x', which is consistent with GCC. 2. Storing the decls in FunctionDecl in ActOnFunctionDeclarator so that they could be used in ActOnStartOfFunctionDef. This is just an inefficient way to move information around. The AST lives forever, but the list of non-parameter decls in prototype scope is short lived. Moving these things to the Declarator solves both of these issues. Reviewers: rsmith Subscribers: jmolloy, cfe-commits Differential Revision: https://reviews.llvm.org/D27279 llvm-svn: 289225
2016-12-10 01:14:05 +08:00
/*DeclsInPrototype=*/None,
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
}
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.
Place implictly declared functions at block scope Such implicitly declared functions behave as if the enclosing block contained the declaration extern int name() (C90, 6.3.3.2 Function calls), thus their names should have block scope (C90, 6.1.2.1 Scope of identifiers). This patch fixes https://bugs.llvm.org/show_bug.cgi?id=33224 Differential Revision: https://reviews.llvm.org/D33676 llvm-svn: 310616
2017-08-10 23:43:06 +08:00
unsigned ScopeFlags = Scope::BlockScope | Scope::FnScope | Scope::DeclScope |
Scope::CompoundStmtScope;
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
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();
Parse: Don't crash when trailing return type is missing Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo. Don't let the AST contain the malformed lambda. This fixes PR22122. llvm-svn: 225505
2015-01-09 13:10:55 +08:00
if (!Stmt.isInvalid() && !TrailingReturnType.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());
Parse: Don't crash when trailing return type is missing Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo. Don't let the AST contain the malformed lambda. This fixes PR22122. llvm-svn: 225505
2015-01-09 13:10:55 +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.
[NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum. Note, we don't do any bitwise manipulations when using them. llvm-svn: 321546
2017-12-29 13:41:00 +08:00
Declarator DeclaratorInfo(DS, DeclaratorContext::TypeNameContext);
[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
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
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.
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext Unevaluated(
Actions, Sema::ExpressionEvaluationContext::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 {
[NFC, Scoped Enum] Convert Sema::ExpressionEvaluationContext into a scoped Enum - also replace direct equality checks against the ConstantEvaluated enumerator with isConstantEvaluted(), in anticipation of adding finer granularity to the various ConstantEvaluated contexts and reinstating certain restrictions on where lambda expressions can occur in C++17. - update the clang tablegen backend that uses these Enumerators, and add the relevant scope where needed. llvm-svn: 299316
2017-04-02 05:30:49 +08:00
EnterExpressionEvaluationContext Unevaluated(
Actions, Sema::ExpressionEvaluationContext::Unevaluated);
Microsoft's __uuidof operator implementation part 1. llvm-svn: 113356
2010-09-08 20:20:18 +08:00
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
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parse a C++ pseudo-destructor expression after the base,
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
/// . 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());
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
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
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);
Again reverting an attempt to convert the DeclSpec enums into scoped enums. - reverts r321622, r321625, and r321626. - the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen. - to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change. So in short - I give up (for now at least). Sorry about the noise. llvm-svn: 321628
2018-01-02 02:23:28 +08:00
if (DS.getTypeSpecType() == TST_error)
Support decltype in pseudo destructors and dependent destructor calls. Reviewed by Eli Friedman. llvm-svn: 146738
2011-12-17 00:03:09 +08:00
return ExprError();
Sema: Parenthesized bound destructor member expressions can be called We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
2015-02-26 01:36:15 +08:00
return Actions.ActOnPseudoDestructorExpr(getCurScope(), Base, OpLoc, OpKind,
TildeLoc, 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
}
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();
Sema: Parenthesized bound destructor member expressions can be called We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
2015-02-26 01:36:15 +08:00
return Actions.ActOnPseudoDestructorExpr(getCurScope(), Base, OpLoc, OpKind,
SS, FirstTypeName, CCLoc, TildeLoc,
SecondTypeName);
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
}
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
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parse the C++ Coroutines co_yield expression.
[coroutines] Add parsing support for co_await expression, co_yield expression, co_await modifier on range-based for loop, co_return statement. llvm-svn: 250985
2015-10-22 12:46:14 +08:00
///
/// co_yield-expression:
/// 'co_yield' assignment-expression[opt]
ExprResult Parser::ParseCoyieldExpression() {
assert(Tok.is(tok::kw_co_yield) && "Not co_yield!");
SourceLocation Loc = ConsumeToken();
[coroutines] Support braced-init-list as operand of co_yield expression. llvm-svn: 253726
2015-11-21 06:47:10 +08:00
ExprResult Expr = Tok.is(tok::l_brace) ? ParseBraceInitializer()
: ParseAssignmentExpression();
[coroutines] Initial stub Sema functionality for handling coroutine await / yield / return. llvm-svn: 250993
2015-10-22 14:13:50 +08:00
if (!Expr.isInvalid())
[coroutines] Creation of promise object, lookup of operator co_await, building of await_* calls, and AST representation for same. llvm-svn: 251387
2015-10-27 14:02:45 +08:00
Expr = Actions.ActOnCoyieldExpr(getCurScope(), Loc, Expr.get());
[coroutines] Add parsing support for co_await expression, co_yield expression, co_await modifier on range-based for loop, co_return statement. llvm-svn: 250985
2015-10-22 12:46:14 +08:00
return Expr;
}
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
///
PR0091R3: Implement parsing support for using templates as types. This change adds a new type node, DeducedTemplateSpecializationType, to represent a type template name that has been used as a type. This is modeled around AutoType, and shares a common base class for representing a deduced placeholder type. We allow deduced class template types in a few more places than the standard does: in conditions and for-range-declarators, and in new-type-ids. This is consistent with GCC and with discussion on the core reflector. This patch does not yet support deduced class template types being named in typename specifiers. llvm-svn: 293207
2017-01-27 04:40:47 +08:00
/// In C++1z onwards, the type specifier can also be a template-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
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) {
[NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum. Note, we don't do any bitwise manipulations when using them. llvm-svn: 321546
2017-12-29 13:41:00 +08:00
Declarator DeclaratorInfo(DS, DeclaratorContext::FunctionalCastContext);
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();
[Parse] Forward brace locations to TypeConstructExpr When parsing C++ type construction expressions with list initialization, forward the locations of the braces to Sema. Without these locations, the code coverage pass crashes on the given test case, because the pass relies on getLocEnd() returning a valid location. Here is what this patch does in more detail: - Forwards init-list brace locations to Sema (ParseExprCXX), - Builds an InitializationKind with these locations (SemaExprCXX), and - Uses these locations for constructor initialization (SemaInit). The remaining changes fall out of introducing a new overload for creating direct-list InitializationKinds. Testing: check-clang, and a stage2 coverage-enabled build of clang with asserts enabled. Differential Revision: https://reviews.llvm.org/D41921 llvm-svn: 322729
2018-01-18 02:53:51 +08:00
return Actions.ActOnCXXTypeConstructExpr(
TypeRep, InitList->getLocStart(), MultiExprArg(&InitList, 1),
InitList->getLocEnd(), /*ListInitialization=*/true);
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)) {
Initial support for C++ parameter completion The improved completion in call context now works with: - Functions. - Member functions. - Constructors. - New expressions. - Function call expressions. - Template variants of the previous. There are still rough edges to be fixed: - Provide support for optional parameters. (fix known) - Provide support for member initializers. (fix known) - Provide support for variadic template functions. (fix unknown) - Others? llvm-svn: 226670
2015-01-22 00:24:11 +08:00
if (ParseExpressionList(Exprs, CommaLocs, [&] {
Actions.CodeCompleteConstructor(getCurScope(),
TypeRep.get()->getCanonicalTypeInternal(),
DS.getLocEnd(), Exprs);
})) {
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!");
[Parse] Forward brace locations to TypeConstructExpr When parsing C++ type construction expressions with list initialization, forward the locations of the braces to Sema. Without these locations, the code coverage pass crashes on the given test case, because the pass relies on getLocEnd() returning a valid location. Here is what this patch does in more detail: - Forwards init-list brace locations to Sema (ParseExprCXX), - Builds an InitializationKind with these locations (SemaExprCXX), and - Uses these locations for constructor initialization (SemaInit). The remaining changes fall out of introducing a new overload for creating direct-list InitializationKinds. Testing: check-clang, and a stage2 coverage-enabled build of clang with asserts enabled. Differential Revision: https://reviews.llvm.org/D41921 llvm-svn: 322729
2018-01-18 02:53:51 +08:00
return Actions.ActOnCXXTypeConstructExpr(TypeRep, T.getOpenLocation(),
Exprs, T.getCloseLocation(),
/*ListInitialization=*/false);
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
Allow conditions to be decomposed with structured bindings Summary: This feature was discussed but not yet proposed. It allows a structured binding to appear as a //condition// if (auto [ok, val] = f(...)) So the user can save an extra //condition// if the statement can test the value to-be-decomposed instead. Formally, it makes the value of the underlying object of the structured binding declaration also the value of a //condition// that is an initialized declaration. Considering its logicality which is entirely evident from its trivial implementation, I think it might be acceptable to land it as an extension for now before I write the paper. Reviewers: rsmith, faisalv, aaron.ballman Reviewed By: rsmith Subscribers: aaron.ballman, cfe-commits Differential Revision: https://reviews.llvm.org/D39284 llvm-svn: 320011
2017-12-07 15:03:15 +08:00
/// [Clang] type-specifier-seq ref-qualifier[opt] '[' identifier-list ']'
/// brace-or-equal-initializer
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
///
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
/// In C++1z, a condition may in some contexts be preceded by an
/// optional init-statement. This function will parse that too.
///
/// \param InitStmt If non-null, an init-statement is permitted, and if present
/// will be parsed and stored here.
///
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.
///
Re-commit r273548, reverted in r273589, with a fix to not produce -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
2016-06-24 03:02:52 +08:00
/// \returns The parsed condition.
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
Sema::ConditionResult Parser::ParseCXXCondition(StmtResult *InitStmt,
SourceLocation Loc,
Re-commit r273548, reverted in r273589, with a fix to not produce -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
2016-06-24 03:02:52 +08:00
Sema::ConditionKind CK) {
Diagnose missing 'template' keywords in more cases. We track when we see a name-shaped expression followed by a '<' token and parse the '<' as a comparison. Then: * if we see a token sequence that cannot possibly be an expression but can be a template argument (in particular, a type-id) that follows either a ',' or the '<', diagnose that the '<' was supposed to start a template argument list, and * if we see '>()', diagnose that the '<' was supposed to start a template argument list. This only changes the diagnostic for error cases, and in practice appears to catch the most common cases where a missing 'template' keyword leads to parse errors within a template. Differential Revision: https://reviews.llvm.org/D48571 llvm-svn: 335687
2018-06-27 07:20:26 +08:00
ParenBraceBracketBalancer BalancerRAIIObj(*this);
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();
Re-commit r273548, reverted in r273589, with a fix to not produce -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
2016-06-24 03:02:52 +08:00
return Sema::ConditionError();
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
[C++17] Allow an empty expression in an if init statement Summary: This fixes [PR35381](https://llvm.org/pr35381) and an additional bug where clang didn't warn about the C++17 extension when having an expression in the init statement. Thanks Nicolas Lesser for contributing the patch. Reviewers: rsmith Reviewed By: rsmith Subscribers: erik.pilkington, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D40445 llvm-svn: 327782
2018-03-18 05:42:10 +08:00
const auto WarnOnInit = [this, &CK] {
Diag(Tok.getLocation(), getLangOpts().CPlusPlus17
? diag::warn_cxx14_compat_init_statement
: diag::ext_init_statement)
<< (CK == Sema::ConditionKind::Switch);
};
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
// Determine what kind of thing we have.
switch (isCXXConditionDeclarationOrInitStatement(InitStmt)) {
case ConditionOrInitStatement::Expression: {
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);
[C++17] Allow an empty expression in an if init statement Summary: This fixes [PR35381](https://llvm.org/pr35381) and an additional bug where clang didn't warn about the C++17 extension when having an expression in the init statement. Thanks Nicolas Lesser for contributing the patch. Reviewers: rsmith Reviewed By: rsmith Subscribers: erik.pilkington, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D40445 llvm-svn: 327782
2018-03-18 05:42:10 +08:00
// We can have an empty expression here.
// if (; true);
if (InitStmt && Tok.is(tok::semi)) {
WarnOnInit();
SourceLocation SemiLoc = ConsumeToken();
*InitStmt = Actions.ActOnNullStmt(SemiLoc);
return ParseCXXCondition(nullptr, Loc, CK);
}
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.
Re-commit r273548, reverted in r273589, with a fix to not produce -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
2016-06-24 03:02:52 +08:00
ExprResult Expr = ParseExpression(); // expression
if (Expr.isInvalid())
return Sema::ConditionError();
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
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
if (InitStmt && Tok.is(tok::semi)) {
[C++17] Allow an empty expression in an if init statement Summary: This fixes [PR35381](https://llvm.org/pr35381) and an additional bug where clang didn't warn about the C++17 extension when having an expression in the init statement. Thanks Nicolas Lesser for contributing the patch. Reviewers: rsmith Reviewed By: rsmith Subscribers: erik.pilkington, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D40445 llvm-svn: 327782
2018-03-18 05:42:10 +08:00
WarnOnInit();
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
*InitStmt = Actions.ActOnExprStmt(Expr.get());
ConsumeToken();
return ParseCXXCondition(nullptr, Loc, CK);
}
Re-commit r273548, reverted in r273589, with a fix to not produce -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
2016-06-24 03:02:52 +08:00
return Actions.ActOnCondition(getCurScope(), Loc, Expr.get(), CK);
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
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
case ConditionOrInitStatement::InitStmtDecl: {
[C++17] Allow an empty expression in an if init statement Summary: This fixes [PR35381](https://llvm.org/pr35381) and an additional bug where clang didn't warn about the C++17 extension when having an expression in the init statement. Thanks Nicolas Lesser for contributing the patch. Reviewers: rsmith Reviewed By: rsmith Subscribers: erik.pilkington, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D40445 llvm-svn: 327782
2018-03-18 05:42:10 +08:00
WarnOnInit();
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
SourceLocation DeclStart = Tok.getLocation(), DeclEnd;
[NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum. Note, we don't do any bitwise manipulations when using them. llvm-svn: 321546
2017-12-29 13:41:00 +08:00
DeclGroupPtrTy DG =
ParseSimpleDeclaration(DeclaratorContext::InitStmtContext, DeclEnd,
attrs, /*RequireSemi=*/true);
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
*InitStmt = Actions.ActOnDeclStmt(DG, DeclStart, DeclEnd);
return ParseCXXCondition(nullptr, Loc, CK);
}
case ConditionOrInitStatement::ConditionDecl:
case ConditionOrInitStatement::Error:
break;
}
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);
[NFC] Modernize enum DeclSpecContext into a scoped enum. llvm-svn: 321590
2017-12-31 08:06:40 +08:00
ParseSpecifierQualifierList(DS, AS_none, DeclSpecContext::DSC_condition);
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
// declarator
[NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum. Note, we don't do any bitwise manipulations when using them. llvm-svn: 321546
2017-12-29 13:41:00 +08:00
Declarator DeclaratorInfo(DS, DeclaratorContext::ConditionContext);
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
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);
Re-commit r273548, reverted in r273589, with a fix to not produce -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
2016-06-24 03:02:52 +08:00
return Sema::ConditionError();
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);
Re-commit r273548, reverted in r273589, with a fix to not produce -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
2016-06-24 03:02:52 +08:00
if (Dcl.isInvalid())
return Sema::ConditionError();
Decl *DeclOut = Dcl.get();
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();
Re-commit r273548, reverted in r273589, with a fix to not produce -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
2016-06-24 03:02:52 +08:00
Diag(DeclOut->getLocation(),
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::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 {
Re-commit r273548, reverted in r273589, with a fix to not produce -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
2016-06-24 03:02:52 +08:00
Diag(DeclOut->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())
Remove redundant passing around of a "ContainsAutoType" flag. This flag serves no purpose other than to prevent us walking through a type to check whether it contains an 'auto' specifier; this duplication of information is error-prone, does not appear to provide any performance benefit, and will become less practical once we support C++1z deduced class template types and eventually constrained types from the Concepts TS. No functionality change intended. llvm-svn: 291737
2017-01-12 10:27:38 +08:00
Actions.AddInitializerToDecl(DeclOut, InitExpr.get(), !CopyInitialization);
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
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);
Re-commit r273548, reverted in r273589, with a fix to not produce -Wfor-loop-analysis warnings for a for-loop with a condition variable. In such a case, the loop condition variable is modified on each iteration of the loop by definition. Original commit message: Rearrange condition handling so that semantic checks on a condition variable are performed before the other substatements of the construct are parsed, rather than deferring them until the end. This allows better error recovery from semantic errors in the condition, improves diagnostic order, and is a prerequisite for C++17 constexpr if. llvm-svn: 273600
2016-06-24 03:02:52 +08:00
return Actions.ActOnConditionVariable(DeclOut, Loc, CK);
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());
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
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
Fix a layering oddity by passing Sema to DeclSpec::Finish instead of DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema. llvm-svn: 253158
2015-11-15 11:32:11 +08:00
DS.Finish(Actions, 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;
Recommit "Add _Float16 as a C/C++ source language type" This is a recommit of r312781; in some build configurations variable names are omitted, so changed the new regression test accordingly. llvm-svn: 312794
2017-09-08 23:15:00 +08:00
case tok::kw__Float16:
DS.SetTypeSpecType(DeclSpec::TST_float16, Loc, PrevSpec, DiagID, Policy);
break;
Enable support for __float128 in Clang and enable it on pertinent platforms This patch corresponds to reviews: http://reviews.llvm.org/D15120 http://reviews.llvm.org/D19125 It adds support for the __float128 keyword, literals and target feature to enable it. Based on the latter of the two aforementioned reviews, this feature is enabled on Linux on i386/X86 as well as SystemZ. This is also the second attempt in commiting this feature. The first attempt did not enable it on required platforms which caused failures when compiling type_traits with -std=gnu++11. If you see failures with compiling this header on your platform after this commit, it is likely that your platform needs to have this feature enabled. llvm-svn: 268898
2016-05-09 16:52:33 +08:00
case tok::kw___float128:
DS.SetTypeSpecType(DeclSpec::TST_float128, Loc, PrevSpec, DiagID, Policy);
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_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;
Implement P0482R2, support for char8_t type. This is not yet part of any C++ working draft, and so is controlled by the flag -fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a flag with the same name.) This implementation is experimental, and will be removed or revised substantially to match the proposal as it makes its way through the C++ committee. llvm-svn: 331244
2018-05-01 13:02:45 +08:00
case tok::kw_char8_t:
DS.SetTypeSpecType(DeclSpec::TST_char8, Loc, PrevSpec, DiagID, Policy);
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 a layering oddity by passing Sema to DeclSpec::Finish instead of DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema. llvm-svn: 253158
2015-11-15 11:32:11 +08:00
return DS.Finish(Actions, 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 a layering oddity by passing Sema to DeclSpec::Finish instead of DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema. llvm-svn: 253158
2015-11-15 11:32:11 +08:00
DS.Finish(Actions, 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;
}
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnyToken();
DS.SetRangeEnd(PrevTokLocation);
Fix a layering oddity by passing Sema to DeclSpec::Finish instead of DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema. llvm-svn: 253158
2015-11-15 11:32:11 +08:00
DS.Finish(Actions, 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) {
[NFC] Modernize enum DeclSpecContext into a scoped enum. llvm-svn: 321590
2017-12-31 08:06:40 +08:00
ParseSpecifierQualifierList(DS, AS_none, DeclSpecContext::DSC_type_specifier);
Fix a layering oddity by passing Sema to DeclSpec::Finish instead of DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema. llvm-svn: 253158
2015-11-15 11:32:11 +08:00
DS.Finish(Actions, 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;
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Finish parsing a C++ unqualified-id that is a template-id 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
/// 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) {
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
assert(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()) {
[NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum UnqualifiedIdKind. llvm-svn: 321574
2017-12-30 12:15:27 +08:00
case UnqualifiedIdKind::IK_Identifier:
case UnqualifiedIdKind::IK_OperatorFunctionId:
case UnqualifiedIdKind::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) {
Finish implementation of C++ DR1310 (http://wg21.link/cwg1310). Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
2017-01-20 08:20:39 +08:00
// We defer the injected-class-name checks until we've found whether
// this template-id is used to form a nested-name-specifier or not.
TNK = Actions.ActOnDependentTemplateName(
getCurScope(), SS, TemplateKWLoc, Id, ObjectType, EnteringContext,
Template, /*AllowInjectedClassName*/ 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
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;
[NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum UnqualifiedIdKind. llvm-svn: 321574
2017-12-30 12:15:27 +08:00
if (Id.getKind() == UnqualifiedIdKind::IK_Identifier)
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
Name = Id.Identifier->getName();
else {
Name = "operator ";
[NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum UnqualifiedIdKind. llvm-svn: 321574
2017-12-30 12:15:27 +08:00
if (Id.getKind() == UnqualifiedIdKind::IK_OperatorFunctionId)
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
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 ");
Finish implementation of C++ DR1310 (http://wg21.link/cwg1310). Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
2017-01-20 08:20:39 +08:00
TNK = Actions.ActOnDependentTemplateName(
getCurScope(), SS, TemplateKWLoc, Id, ObjectType, EnteringContext,
Template, /*AllowInjectedClassName*/ 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
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;
[NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum UnqualifiedIdKind. llvm-svn: 321574
2017-12-30 12:15:27 +08:00
case UnqualifiedIdKind::IK_ConstructorName: {
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;
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
[NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum UnqualifiedIdKind. llvm-svn: 321574
2017-12-30 12:15:27 +08:00
case UnqualifiedIdKind::IK_DestructorName: {
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;
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) {
Finish implementation of C++ DR1310 (http://wg21.link/cwg1310). Diagnose the case when a dependent template name instantiates to an injected-class-name outside a nested-name-specifier. llvm-svn: 292545
2017-01-20 08:20:39 +08:00
TNK = Actions.ActOnDependentTemplateName(
getCurScope(), SS, TemplateKWLoc, TemplateName, ObjectType,
EnteringContext, Template, /*AllowInjectedClassName*/ 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
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;
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
if (ParseTemplateIdAfterTemplateName(true, LAngleLoc, TemplateArgs,
RAngleLoc))
Introduce a new class, UnqualifiedId, that provides a parsed representation of a C++ unqualified-id, along with a single parsing function (Parser::ParseUnqualifiedId) that will parse all of the various forms of unqualified-id in C++. Replace the representation of the declarator name in Declarator with the new UnqualifiedId class, simplifying declarator-id parsing considerably and providing more source-location information to Sema. In the future, I hope to migrate all of the other unqualified-id-parsing code over to this single representation, then begin to merge actions that are currently only different because we didn't have a unqualified notion of the name in the parser. llvm-svn: 85851
2009-11-03 09:35:08 +08:00
return true;
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
[NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum UnqualifiedIdKind. llvm-svn: 321574
2017-12-30 12:15:27 +08:00
if (Id.getKind() == UnqualifiedIdKind::IK_Identifier ||
Id.getKind() == UnqualifiedIdKind::IK_OperatorFunctionId ||
Id.getKind() == UnqualifiedIdKind::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.
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.
[NFC, Refactor] Modernize TemplateIdAnnotation using TrailingObjects A refactoring of TemplateIdAnnotation that uses TrailingObjects to create a variably-sized object on the heap. https://reviews.llvm.org/D31414 Thanks to Aaron B for the review! llvm-svn: 303594
2017-05-23 09:07:12 +08:00
IdentifierInfo *TemplateII =
[NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum UnqualifiedIdKind. llvm-svn: 321574
2017-12-30 12:15:27 +08:00
Id.getKind() == UnqualifiedIdKind::IK_Identifier ? Id.Identifier
: nullptr;
OverloadedOperatorKind OpKind =
Id.getKind() == UnqualifiedIdKind::IK_Identifier
? OO_None
: Id.OperatorFunctionId.Operator;
[NFC, Refactor] Modernize TemplateIdAnnotation using TrailingObjects A refactoring of TemplateIdAnnotation that uses TrailingObjects to create a variably-sized object on the heap. https://reviews.llvm.org/D31414 Thanks to Aaron B for the review! llvm-svn: 303594
2017-05-23 09:07:12 +08:00
TemplateIdAnnotation *TemplateId = TemplateIdAnnotation::Create(
SS, TemplateKWLoc, Id.StartLocation, TemplateII, OpKind, Template, TNK,
LAngleLoc, RAngleLoc, TemplateArgs, 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
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,
PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310). Under this defect resolution, the injected-class-name of a class or class template cannot be used except in very limited circumstances (when declaring a constructor, in a nested-name-specifier, in a base-specifier, or in an elaborated-type-specifier). This is apparently done to make parsing easier, but it's a pain for us since we don't know whether a template-id using the injected-class-name is valid at the point when we annotate it (we don't yet know whether the template-id will become part of an elaborated-type-specifier). As a tentative resolution to a perceived language defect, mem-initializer-ids are added to the list of exceptions here (they generally follow the same rules as base-specifiers). When the reference to the injected-class-name uses the 'typename' or 'template' keywords, we permit it to be used to name a type or template as an extension; other compilers also accept some cases in this area. There are also a couple of corner cases with dependent template names that we do not yet diagnose, but which will also get this treatment. llvm-svn: 292518
2017-01-20 05:00:13 +08:00
Template, Name, 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;
[NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum UnqualifiedIdKind. llvm-svn: 321574
2017-12-30 12:15:27 +08:00
if (Id.getKind() == UnqualifiedIdKind::IK_ConstructorName)
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
Id.setConstructorName(Type.get(), NameLoc, RAngleLoc);
else
Id.setDestructorName(Id.StartLocation, Type.get(), RAngleLoc);
return false;
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parse an operator-function-id or conversion-function-id as part
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
/// 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[]
/// + - * / % ^ & | ~
/// ! = < > += -= *= /= %=
/// ^= &= |= << >> >>= <<= == !=
/// <= >= && || ++ -- , ->* ->
[c++2a] P0515R3: Support for overloaded operator<=>. No CodeGen support for MSABI yet, we don't know how to mangle this there. llvm-svn: 319513
2017-12-01 10:13:10 +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
///
/// 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;
When pretty-printing a C++11 literal operator, don't insert whitespace between the "" and the suffix; that breaks names such as 'operator""if'. For symmetry, also remove the space between the 'operator' and the '""'. llvm-svn: 249641
2015-10-08 08:17:59 +08:00
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 += 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.
[NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum. Note, we don't do any bitwise manipulations when using them. llvm-svn: 321546
2017-12-29 13:41:00 +08:00
Declarator D(DS, DeclaratorContext::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;
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parse a C++ unqualified-id (or a C identifier), which describes the
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
/// 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.
///
P0091R3: Implement basic parsing support for C++17 deduction-guides. We model deduction-guides as functions with a new kind of name that identifies the template whose deduction they guide; the bulk of this patch is adding the new name kind. This gives us a clean way to attach an extensible list of guides to a class template in a way that doesn't require any special handling in AST files etc (and we're going to need these functions we come to performing deduction). llvm-svn: 294266
2017-02-07 09:37:30 +08:00
/// \param AllowDeductionGuide whether we allow parsing a deduction guide 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,
P0091R3: Implement basic parsing support for C++17 deduction-guides. We model deduction-guides as functions with a new kind of name that identifies the template whose deduction they guide; the bulk of this patch is adding the new name kind. This gives us a clean way to attach an extensible list of guides to a class template in a way that doesn't require any special handling in AST files etc (and we're going to need these functions we come to performing deduction). llvm-svn: 294266
2017-02-07 09:37:30 +08:00
bool AllowDeductionGuide,
Abstract out passing around types and kill off ActionBase. llvm-svn: 111901
2010-08-24 13:47:05 +08:00
ParsedType ObjectType,
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +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) {
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
if (TemplateKWLoc)
*TemplateKWLoc = SourceLocation();
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;
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
if (Tok.is(tok::kw_template)) {
if (TemplateKWLoc && (ObjectType || SS.isSet())) {
TemplateSpecified = true;
*TemplateKWLoc = ConsumeToken();
} else {
SourceLocation TemplateLoc = ConsumeToken();
Diag(TemplateLoc, diag::err_unexpected_template_in_unqualified_id)
<< FixItHint::CreateRemoval(TemplateLoc);
}
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
}
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;
}
P0091R3: Implement basic parsing support for C++17 deduction-guides. We model deduction-guides as functions with a new kind of name that identifies the template whose deduction they guide; the bulk of this patch is adding the new name kind. This gives us a clean way to attach an extensible list of guides to a class template in a way that doesn't require any special handling in AST files etc (and we're going to need these functions we come to performing deduction). llvm-svn: 294266
2017-02-07 09:37:30 +08:00
ParsedTemplateTy TemplateName;
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.
Restore pre-r335182 behavior for naming inherited constructors as members of dependent contexts. This permits cases where the names before and after the '::' in a dependent inherited constructor using-declaration do not match, but where we can nonetheless tell when parsing the template that a constructor is being named. Under (open) core language DR 2070, such cases will probably be ill-formed, but r335182 does not quite give that result and didn't intend to change this, so restore the old behavior for now. llvm-svn: 335381
2018-06-23 03:50:19 +08:00
ParsedType Ty = Actions.getConstructorName(*Id, IdLoc, getCurScope(), SS,
EnteringContext);
Related to PR37768: improve diagnostics for class name shadowing. Diagnose the name of the class being shadowed by using declarations, and improve the diagnostics for the case where the name of the class is shadowed by a non-static data member in a class with constructors. In the latter case, we now always give the "member with the same name as its class" diagnostic regardless of the relative order of the member and the constructor, rather than giving an inscrutible diagnostic if the constructor appears second. llvm-svn: 335182
2018-06-21 05:58:20 +08:00
if (!Ty)
return true;
Avoid redundant NNS qualification in constructor/destructor names. llvm-svn: 149124
2012-01-27 16:46:19 +08:00
Result.setConstructorName(Ty, IdLoc, IdLoc);
Now that C++17 is official (https://www.iso.org/standard/68564.html), start changing the C++1z terminology over to C++17. NFC intended, these are all mechanical changes. llvm-svn: 319688
2017-12-05 04:27:34 +08:00
} else if (getLangOpts().CPlusPlus17 &&
P0091R3: Implement basic parsing support for C++17 deduction-guides. We model deduction-guides as functions with a new kind of name that identifies the template whose deduction they guide; the bulk of this patch is adding the new name kind. This gives us a clean way to attach an extensible list of guides to a class template in a way that doesn't require any special handling in AST files etc (and we're going to need these functions we come to performing deduction). llvm-svn: 294266
2017-02-07 09:37:30 +08:00
AllowDeductionGuide && SS.isEmpty() &&
Actions.isDeductionGuideName(getCurScope(), *Id, IdLoc,
&TemplateName)) {
// We have parsed a template-name naming a deduction guide.
Result.setDeductionGuideName(TemplateName, 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.
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
TemplateTy Template;
if (Tok.is(tok::less))
return ParseUnqualifiedIdTemplateId(
SS, TemplateKWLoc ? *TemplateKWLoc : SourceLocation(), Id, IdLoc,
EnteringContext, ObjectType, Result, TemplateSpecified);
else if (TemplateSpecified &&
Actions.ActOnDependentTemplateName(
getCurScope(), SS, *TemplateKWLoc, Result, ObjectType,
EnteringContext, Template,
/*AllowInjectedClassName*/ true) == TNK_Non_template)
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
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));
Related to PR37768: improve diagnostics for class name shadowing. Diagnose the name of the class being shadowed by using declarations, and improve the diagnostics for the case where the name of the class is shadowed by a non-static data member in a class with constructors. In the latter case, we now always give the "member with the same name as its class" diagnostic regardless of the relative order of the member and the constructor, rather than giving an inscrutible diagnostic if the constructor appears second. llvm-svn: 335182
2018-06-21 05:58:20 +08:00
ParsedType Ty = Actions.getConstructorName(
Restore pre-r335182 behavior for naming inherited constructors as members of dependent contexts. This permits cases where the names before and after the '::' in a dependent inherited constructor using-declaration do not match, but where we can nonetheless tell when parsing the template that a constructor is being named. Under (open) core language DR 2070, such cases will probably be ill-formed, but r335182 does not quite give that result and didn't intend to change this, so restore the old behavior for now. llvm-svn: 335381
2018-06-23 03:50:19 +08:00
*TemplateId->Name, TemplateId->TemplateNameLoc, getCurScope(), SS,
EnteringContext);
Related to PR37768: improve diagnostics for class name shadowing. Diagnose the name of the class being shadowed by using declarations, and improve the diagnostics for the case where the name of the class is shadowed by a non-static data member in a class with constructors. In the latter case, we now always give the "member with the same name as its class" diagnostic regardless of the relative order of the member and the constructor, rather than giving an inscrutible diagnostic if the constructor appears second. llvm-svn: 335182
2018-06-21 05:58:20 +08:00
if (!Ty)
return true;
Avoid redundant NNS qualification in constructor/destructor names. llvm-svn: 149124
2012-01-27 16:46:19 +08:00
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);
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
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
return false;
}
Result.setConstructorTemplateId(TemplateId);
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
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
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);
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
SourceLocation TemplateLoc = TemplateId->TemplateKWLoc;
if (TemplateLoc.isValid()) {
if (TemplateKWLoc && (ObjectType || SS.isSet()))
*TemplateKWLoc = TemplateLoc;
else
Diag(TemplateLoc, diag::err_unexpected_template_in_unqualified_id)
<< FixItHint::CreateRemoval(TemplateLoc);
}
Fix the location of "missing ';'" suggestions after annotation tokens. We were incorrectly setting PrevTokLocation to the first token in the annotation token instead of the last when consuming it. To fix this without adding a complex switch to the hot path through ConsumeToken, we now have a ConsumeAnnotationToken function for consuming annotation tokens in addition to the other Consume*Token special case functions. llvm-svn: 303372
2017-05-19 03:21:48 +08:00
ConsumeAnnotationToken();
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:
// 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] >
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
TemplateTy Template;
[NFC] Modernize enum 'UnqualifiedId::IdKind' into a scoped enum UnqualifiedIdKind. llvm-svn: 321574
2017-12-30 12:15:27 +08:00
if ((Result.getKind() == UnqualifiedIdKind::IK_OperatorFunctionId ||
Result.getKind() == UnqualifiedIdKind::IK_LiteralOperatorId) &&
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
Tok.is(tok::less))
return ParseUnqualifiedIdTemplateId(
SS, TemplateKWLoc ? *TemplateKWLoc : SourceLocation(), nullptr,
SourceLocation(), EnteringContext, ObjectType, Result,
TemplateSpecified);
else if (TemplateSpecified &&
Actions.ActOnDependentTemplateName(
getCurScope(), SS, *TemplateKWLoc, Result, ObjectType,
EnteringContext, Template,
/*AllowInjectedClassName*/ true) == TNK_Non_template)
return true;
[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);
More fixes for places where 'decltype(auto)' is permitted in the C++ grammar but makes no sense. llvm-svn: 294509
2017-02-09 04:39:08 +08:00
if (ParsedType Type =
Actions.getDestructorTypeForDecltype(DS, ObjectType)) {
Decltype in non-pseudo (& non-dependent) dtor calls. llvm-svn: 146155
2011-12-09 00:13:53 +08:00
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.
Fix crash-on-invalid and name lookup when recovering from ~X::X() typo. llvm-svn: 226067
2015-01-15 08:48:52 +08:00
DeclaratorScopeObj DeclScopeObj(*this, SS);
Remove a comment I accidentally added in r227581. No behavior change. llvm-svn: 227777
2015-02-02 12:18:38 +08:00
if (!TemplateSpecified && NextToken().is(tok::coloncolon)) {
Follow-up to r217302 and r227555: Don't crash on inline ~A::A() if A is an int. Even with r227555, this still crashed: struct S { int A; ~A::A() {} }; That's because ParseOptionalCXXScopeSpecifier()'s call to ActOnCXXNestedNameSpecifier() doesn't mark the scope spec as invalid if sema thought it's a good idea to fixit-correct "::" to ":". For the diagnostic improvement done in r217302, we never want :: to be interpreted as :, so fix this by setting ColonSacred to false temporarily. Found by SLi's bot. llvm-svn: 227581
2015-01-31 00:53:11 +08:00
// Don't let ParseOptionalCXXScopeSpecifier() "correct"
// `int A; struct { ~A::A(); };` to `int A; struct { ~A:A(); };`,
// it will confuse this recovery logic.
ColonProtectionRAIIObject ColonRAII(*this, false);
Add error, recovery and fixit for "~A::A() {...}". llvm-svn: 217302
2014-09-06 10:06:12 +08:00
if (SS.isSet()) {
AnnotateScopeToken(SS, /*NewAnnotation*/true);
SS.clear();
}
if (ParseOptionalCXXScopeSpecifier(SS, ObjectType, EnteringContext))
return true;
Follow-up to r217302: Don't crash on ~A::A in a postfix expr suffix followed by '<'. This used to crash, complaining "ObjectType and scope specifier cannot coexist": struct A { } b = b.~A::A <int>; The only other caller of ParseOptionalCXXScopeSpecifier() that passes in a non-empty ObjectType clears the ObjectType of the scope specifier comes back non-empty (see the tok::period case in Parser::ParsePostfixExpressionSuffix()), so do that here too. Found by SLi's bot. llvm-svn: 227781
2015-02-02 13:33:50 +08:00
if (SS.isNotEmpty())
OpaquePtr: Use nullptr construction for ParsedType OpaquePtr typedef llvm-svn: 257958
2016-01-16 07:43:34 +08:00
ObjectType = nullptr;
Follow-up to r217302: Don't crash on ~A::A() if A is undeclared. llvm-svn: 227555
2015-01-30 12:05:15 +08:00
if (Tok.isNot(tok::identifier) || NextToken().is(tok::coloncolon) ||
[Parse] Don't crash on ~A::{ Found by clang-fuzz. llvm-svn: 233492
2015-03-29 22:35:39 +08:00
!SS.isSet()) {
Add error, recovery and fixit for "~A::A() {...}". llvm-svn: 217302
2014-09-06 10:06:12 +08:00
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(), "~");
Fix crash-on-invalid and name lookup when recovering from ~X::X() typo. llvm-svn: 226067
2015-01-15 08:48:52 +08:00
// Temporarily enter the scope for the rest of this function.
if (Actions.ShouldEnterDeclaratorScope(getCurScope(), SS))
DeclScopeObj.EnterDeclaratorScope();
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
// 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
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
if (Tok.is(tok::less)) {
OpaquePtr: Use nullptr construction for ParsedType OpaquePtr typedef llvm-svn: 257958
2016-01-16 07:43:34 +08:00
Result.setDestructorName(TildeLoc, nullptr, ClassNameLoc);
Parse A::template B as an identifier rather than as a template-id with no template arguments. This fixes some cases where we'd incorrectly accept "A::template B" when B is a kind of template that requires template arguments (in particular, a variable template or a concept). llvm-svn: 331013
2018-04-27 10:00:13 +08:00
return ParseUnqualifiedIdTemplateId(
SS, TemplateKWLoc ? *TemplateKWLoc : SourceLocation(), 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);
[NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum. Note, we don't do any bitwise manipulations when using them. llvm-svn: 321546
2017-12-29 13:41:00 +08:00
Declarator DeclaratorInfo(DS, DeclaratorContext::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;
Initial support for C++ parameter completion The improved completion in call context now works with: - Functions. - Member functions. - Constructors. - New expressions. - Function call expressions. - Template variants of the previous. There are still rough edges to be fixed: - Provide support for optional parameters. (fix known) - Provide support for member initializers. (fix known) - Provide support for variadic template functions. (fix unknown) - Others? llvm-svn: 226670
2015-01-22 00:24:11 +08:00
if (ParseExpressionList(ConstructorArgs, CommaLocs, [&] {
ParsedType TypeRep = Actions.ActOnTypeName(getCurScope(),
DeclaratorInfo).get();
Actions.CodeCompleteConstructor(getCurScope(),
TypeRep.get()->getCanonicalTypeInternal(),
DeclaratorInfo.getLocEnd(),
ConstructorArgs);
})) {
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
}
}
Remove \brief commands from doxygen comments. This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
2018-05-09 09:00:01 +08:00
/// Parse the built-in type-trait pseudo-functions that allow
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 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);
OpaquePtr: Use nullptr construction for ParsedType OpaquePtr typedef llvm-svn: 257958
2016-01-16 07:43:34 +08:00
CastTy = nullptr;
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
}
PR23057: fix use-after-free due to local token buffer in ParseCXXAmbiguousParenExpression, by Dmitry Polukhin Differential Revision: http://reviews.llvm.org/D16572 A test/Parser/cxx-ambig-paren-expr-asan.cpp M lib/Parse/ParseExprCXX.cpp llvm-svn: 259750
2016-02-04 12:22:09 +08:00
// Create a fake EOF to mark end of Toks buffer.
Token AttrEnd;
AttrEnd.startToken();
AttrEnd.setKind(tok::eof);
AttrEnd.setLocation(Tok.getLocation());
AttrEnd.setEofData(Toks.data());
Toks.push_back(AttrEnd);
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.
Simplify EnterTokenStream API to make it more robust for memory management While this won't help fix things like the bug that r260219 addressed, it seems like good tidy up to have anyway. (it might be nice if "makeArrayRef" always produced a MutableArrayRef & let it decay to an ArrayRef when needed - then I'd use that for the MutableArrayRefs in this patch) If we had std::dynarray I'd use that instead of unique_ptr+size_t, ideally (but then it'd have to be threaded down through the Preprocessor all the way - no idea how painful that would be) llvm-svn: 260246
2016-02-10 02:52:09 +08:00
PP.EnterTokenStream(Toks, true /*DisableMacroExpansion*/);
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
// 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);
[NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum. Note, we don't do any bitwise manipulations when using them. llvm-svn: 321546
2017-12-29 13:41:00 +08:00
Declarator DeclaratorInfo(DS, DeclaratorContext::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
PR23057: fix use-after-free due to local token buffer in ParseCXXAmbiguousParenExpression, by Dmitry Polukhin Differential Revision: http://reviews.llvm.org/D16572 A test/Parser/cxx-ambig-paren-expr-asan.cpp M lib/Parse/ParseExprCXX.cpp llvm-svn: 259750
2016-02-04 12:22:09 +08:00
// Consume EOF marker for Toks buffer.
assert(Tok.is(tok::eof) && Tok.getEofData() == AttrEnd.getEofData());
ConsumeAnyToken();
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()) {
PR23057: fix use-after-free due to local token buffer in ParseCXXAmbiguousParenExpression, by Dmitry Polukhin Differential Revision: http://reviews.llvm.org/D16572 A test/Parser/cxx-ambig-paren-expr-asan.cpp M lib/Parse/ParseExprCXX.cpp llvm-svn: 259750
2016-02-04 12:22:09 +08:00
while (Tok.isNot(tok::eof))
ConsumeAnyToken();
assert(Tok.getEofData() == AttrEnd.getEofData());
ConsumeAnyToken();
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();
PR23057: fix use-after-free due to local token buffer in ParseCXXAmbiguousParenExpression, by Dmitry Polukhin Differential Revision: http://reviews.llvm.org/D16572 A test/Parser/cxx-ambig-paren-expr-asan.cpp M lib/Parse/ParseExprCXX.cpp llvm-svn: 259750
2016-02-04 12:22:09 +08:00
// Consume EOF marker for Toks buffer.
assert(Tok.is(tok::eof) && Tok.getEofData() == AttrEnd.getEofData());
ConsumeAnyToken();
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
}