summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* When we see a 'template' disambiguator that marks the next identifierDouglas Gregor2010-06-161-36/+38
| | | | | | | | | | | (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
* Fix the recently-added warning about 'typename' and 'template'Douglas Gregor2010-06-161-6/+8
| | | | | | | | | disambiguation keywords outside of templates in C++98/03. Previously, the warning would fire when the associated nested-name-specifier was not dependent, but that was a misreading of the C++98/03 standard: now, we complain only when we're outside of any template. llvm-svn: 106161
* Fix compiler warning about to false -> pointer conversion; patch by Dimitry ↵Daniel Dunbar2010-06-021-1/+1
| | | | | | Andric! llvm-svn: 105328
* Improve code completion in failure cases in two ways:Douglas Gregor2010-05-251-3/+3
| | | | | | | | | | | 1) Suppress diagnostics as soon as we form the code-completion token, so we don't get any error/warning spew from the early end-of-file. 2) If we consume a code-completion token when we weren't expecting one, go into a code-completion recovery path that produces the best results it can based on the context that the parser is in. llvm-svn: 104585
* Improve recovery when we see a dependent template name that is missingDouglas Gregor2010-05-211-0/+25
| | | | | | | | | | | | | | | 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
* Improve parser recovery when we encounter a dependent template nameDouglas Gregor2010-05-211-5/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rework our handling of temporary objects within the conditions ofDouglas Gregor2010-05-061-1/+20
| | | | | | | | | | | | | | | | | | | 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
* Support for 'template' as a disambiguator (PR7030)Douglas Gregor2010-05-051-12/+30
| | | | | | | | | | | | | 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
* Make Parser::ConsumeAndStoreUntil() more consistent with Parser::SkipUntil().Argyrios Kyrtzidis2010-04-231-1/+1
| | | | | | | | | 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
* Implement parsing for message sends in Objective-C++. Message sends inDouglas Gregor2010-04-211-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Objective-C++ have a more complex grammar than in Objective-C (surprise!), because (1) The receiver of an instance message can be a qualified name such as ::I or identity<I>::type. (2) Expressions in C++ can start with a type. The receiver grammar isn't actually ambiguous; it just takes a bit of work to parse past the type before deciding whether we have a type or expression. We do this in two places within the grammar: once for message sends and once when we're determining whether a []'d clause in an initializer list is a message send or a C99 designated initializer. This implementation of Objective-C++ message sends contains one known extension beyond GCC's implementation, which is to permit a typename-specifier as the receiver type for a class message, e.g., [typename compute_receiver_type<T>::type method]; Note that the same effect can be achieved in GCC by way of a typedef, e.g., typedef typename computed_receiver_type<T>::type Computed; [Computed method]; so this is merely a convenience. Note also that message sends still cannot involve dependent types or values. llvm-svn: 102031
* Reinstate my CodeModificationHint -> FixItHint renaming patch, withoutDouglas Gregor2010-03-311-2/+2
| | | | | | the C-only "optimization". llvm-svn: 100022
* Revert r100008, which inexplicably breaks the clang-i686-darwin10 builderDouglas Gregor2010-03-311-2/+2
| | | | llvm-svn: 100018
* Rename CodeModificationHint to FixItHint, since we've been using theDouglas Gregor2010-03-311-2/+2
| | | | | | | term "fix-it" everywhere and even *I* get tired of long names sometimes. No functionality change. llvm-svn: 100008
* Fix an assertion-on-error during tentative constructor parsing byJohn McCall2010-02-261-8/+8
| | | | | | | | | | 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
* Restore the invariant that a nested-name-specifier can only containDouglas Gregor2010-02-251-13/+3
| | | | | | | | | class types, dependent types, and namespaces. I had previously weakened this invariant while working on parsing pseudo-destructor expressions, but recent work in that area has made these changes unnecessary. llvm-svn: 97112
* Make sure that we finish the DeclSpec when parsing a C++Douglas Gregor2010-02-241-0/+1
| | | | | | | | type-specifier-seq. Fixes some conditional-jump-on-unitialized-value errors in valgrind. Also counts as attempt #2 at making the MSVC buildbot happy. llvm-svn: 97077
* ActOnPseudoDestructorExpr now performs all semantic analysis forDouglas Gregor2010-02-241-2/+6
| | | | | | | | | | | | | | | | 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
* Rework parsing of pseudo-destructor expressions and explicitDouglas Gregor2010-02-241-15/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement support for parsing pseudo-destructor expression with a ↵Douglas Gregor2010-02-211-15/+29
| | | | | | | | | | | | 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
* Improve parsing and instantiation of destructor names, so that we canDouglas Gregor2010-02-161-18/+9
| | | | | | | | | | | | | | | | | | | | | | | 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
* In some contexts, type declarations cannot occur. Pass this information down ↵Sebastian Redl2010-02-031-2/+5
| | | | | | to ParseClassSpecifier, to make its decision easier. Fixes PR6200. llvm-svn: 95255
* Reimplement constructor declarator parsing to cope with template-idsDouglas Gregor2010-01-131-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Eliminate an embarrassing performance regression in C/ObjC, where weDouglas Gregor2010-01-111-1/+9
| | | | | | | | | | 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
* Improve code completion by introducing patterns for the various C andDouglas Gregor2010-01-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | 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
* refactor the 'ColonIsSacred' argument to ParseOptionalCXXScopeSpecifierChris Lattner2009-12-101-5/+1
| | | | | | | to be a bool in Parser that is twiddled by the ColonProtectionRAIIObject class. No functionality change. llvm-svn: 91014
* reapply my patch for PR4451, which improves diagnostics for :: vs : confusion.Chris Lattner2009-12-071-2/+24
| | | | | | This time with a fix to bail out when in a dependent context. llvm-svn: 90730
* revert my previous patch, it is breaking something and I don't have timeChris Lattner2009-12-061-24/+2
| | | | | | to fix it ATM. llvm-svn: 90717
* implement PR4451, improving error recovery for a mistaken : where a :: wasChris Lattner2009-12-061-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | intended. On the first testcase in the bug, we now produce: cxx-decl.cpp:12:2: error: unexpected ':' in nested name specifier y:a a2; ^ :: instead of: t.cc:8:1: error: C++ requires a type specifier for all declarations x:a a2; ^ t.cc:8:2: error: invalid token after top level declarator x:a a2; ^ ; t.cc:9:11: error: use of undeclared identifier 'a2' x::a a3 = a2; ^ llvm-svn: 90713
* Introduce the notion of literal types, as specified in C++0x.Sebastian Redl2009-12-031-0/+1
| | | | llvm-svn: 90361
* Add DeclarationName support for C++0x operator literals. They should now work asAlexis Hunt2009-11-291-2/+1
| | | | | | | function names outside of templates - they'll probably cause some damage there as they're largely untested. llvm-svn: 90064
* Fix test and handle IK_LiteralOperatorId in a few more places.Alexis Hunt2009-11-281-5/+9
| | | | llvm-svn: 90030
* Add Parser support for C++0x literal operators ('operator "" i').Alexis Hunt2009-11-281-0/+21
| | | | | | DeclarationName can't handle them yet, so right now Parser just errors out on them. llvm-svn: 90027
* Eliminate CXXConditionDeclExpr with extreme prejudice.Douglas Gregor2009-11-251-17/+33
| | | | | | | | | | | | | | | | | 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
* If a C++ qualified id is followed by a postfix suffix, it is never the directJohn McCall2009-11-221-0/+18
| | | | | | | | | | | | | | operand of an addressof operator, and so we should not treat it as an abstract member-pointer expression and therefore suppress the implicit member access. This is really a well-formedness constraint on expressions: a DeclRefExpr of a FieldDecl or a non-static CXXMethodDecl (or template thereof, or unresolved collection thereof) should not be allowed in an arbitrary location in the AST. Arguably it shouldn't be allowed anywhere and we should have a different expr node type for this. But unfortunately we don't have a good way of enforcing this kind of constraint right now. llvm-svn: 89578
* Added rudimentary C++0x attribute support.Alexis Hunt2009-11-211-1/+1
| | | | | | | | | | | | | | The following attributes are currently supported in C++0x attribute lists (and in GNU ones as well): - align() - semantics believed to be conformant to n3000, except for redeclarations and what entities it may apply to - final - semantics believed to be conformant to CWG issue 817's proposed wording, except for redeclarations - noreturn - semantics believed to be conformant to n3000, except for redeclarations - carries_dependency - currently ignored (this is an optimization hint) llvm-svn: 89543
* Cope with extraneous "template" keyword when providing an out-of-lineDouglas Gregor2009-11-201-2/+3
| | | | | | definition of a member template (or a member thereof). Fixes PR5566. llvm-svn: 89512
* Implement C++ [basic.lookup.classref]p3, which states how the typeDouglas Gregor2009-11-201-2/+2
| | | | | | | | | | | | 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
* Fix speculative parsing of dependent template names inDouglas Gregor2009-11-111-26/+17
| | | | | | | | | | | | | | | | | | | | | | 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
* Improve parsing of template arguments to lay the foundation forDouglas Gregor2009-11-101-13/+3
| | | | | | | | | | | | | | | | | | | | | | handling template template parameters properly. This refactoring: - Parses template template arguments as id-expressions, representing the result of the parse as a template name (Action::TemplateTy) rather than as an expression (lame!). - Represents all parsed template arguments via a new parser-specific type, ParsedTemplateArgument, which stores the kind of template argument (type, non-type, template) along with all of the source information about the template argument. This replaces an ad hoc set of 3 vectors (one for a void*, which was either a type or an expression; one for a bit telling whether the first was a type or an expression; and one for a single source location pointing at the template argument). - Moves TemplateIdAnnotation into the new Parse/Template.h. It never belonged in the Basic library anyway. llvm-svn: 86708
* Improve recovery when we fail to parse the operand of a C++ named cast. ↵Douglas Gregor2009-11-061-7/+1
| | | | | | Fixes PR5210 llvm-svn: 86234
* Eliminate the "old" ways of parsing operator-function-ids andDouglas Gregor2009-11-041-135/+0
| | | | | | | conversion-function-ids; all clients have moved on to ParseUnqualifiedId. llvm-svn: 86028
* Implement support for parsing dependent template-ids that refer toDouglas Gregor2009-11-041-149/+213
| | | | | | | | overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
* Parsing and semantic analysis for template-ids that name overloadedDouglas Gregor2009-11-031-36/+26
| | | | | | | | | | | | 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
* Tweak some comments about unqualified-id and id-expression parsing. No ↵Douglas Gregor2009-11-031-13/+6
| | | | | | functionality change llvm-svn: 85942
* Replace the code that parses member access expressions after "." orDouglas Gregor2009-11-031-82/+44
| | | | | | | | | | | | "->" 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
* Use ParseUnqualifiedId when parsing id-expressions. This eliminatesDouglas Gregor2009-11-031-1/+14
| | | | | | | | | | | yet another copy of the unqualified-id parsing code. Also, use UnqualifiedId to simplify the Action interface for building id-expressions. ActOnIdentifierExpr, ActOnCXXOperatorFunctionIdExpr, ActOnCXXConversionFunctionExpr, and ActOnTemplateIdExpr have all been removed in favor of the new ActOnIdExpression action. llvm-svn: 85904
* Introduce a new class, UnqualifiedId, that provides a parsedDouglas Gregor2009-11-031-0/+413
| | | | | | | | | | | | | | | | 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
* When building and instantiating a template-id reference expression, such asDouglas Gregor2009-10-221-1/+2
| | | | | | | | | | | N::f<int> keep track of the full nested-name-specifier. This is mainly QoI and relatively hard to test; will try to come up with a printing-based test once we also retain the explicit template arguments past overload resolution. llvm-svn: 84869
* C++ code completion after the "operator" keyword. Provide overloadedDouglas Gregor2009-09-181-0/+12
| | | | | | operators, type specifiers, type names, and nested-name-specifiers. llvm-svn: 82264
* Initial implementation of a code-completion interface in Clang. InDouglas Gregor2009-09-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud