summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-51/+49
| | | | llvm-svn: 81346
* Initial stab at implement dependent member references to memberDouglas Gregor2009-09-091-0/+2
| | | | | | | | | | | | | 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
* Rewrite of our handling of name lookup in C++ member access expressions, e.g.,Douglas Gregor2009-09-021-11/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a couple issues with parsing invalid nested-name-specifiers.Eli Friedman2009-08-291-0/+8
| | | | llvm-svn: 80421
* Improve support for out-of-line definitions of nested templates andDouglas Gregor2009-08-251-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Take 2 on AltiVec-style vector initializers. Nate Begeman2009-08-101-2/+3
| | | | | | | | | | | | Fixes PR4704 problems Addresses Eli's patch feedback re: ugly cast code Updates all postfix operators to remove ParenListExprs. While this is awful, no better solution (say, in the parser) is obvious to me. Better solutions welcome. llvm-svn: 78621
* Revert r78535, it is causing a number of failures to build projects.Daniel Dunbar2009-08-101-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | --- Reverse-merging r78535 into '.': D test/Sema/altivec-init.c U include/clang/Basic/DiagnosticSemaKinds.td U include/clang/AST/Expr.h U include/clang/AST/StmtNodes.def U include/clang/Parse/Parser.h U include/clang/Parse/Action.h U tools/clang-cc/clang-cc.cpp U lib/Frontend/PrintParserCallbacks.cpp U lib/CodeGen/CGExprScalar.cpp U lib/Sema/SemaInit.cpp U lib/Sema/Sema.h U lib/Sema/SemaExpr.cpp U lib/Sema/SemaTemplateInstantiateExpr.cpp U lib/AST/StmtProfile.cpp U lib/AST/Expr.cpp U lib/AST/StmtPrinter.cpp U lib/Parse/ParseExpr.cpp U lib/Parse/ParseExprCXX.cpp llvm-svn: 78551
* AltiVec-style vector initializer syntax, vec4 a = (vec4)(a, b, c, d);Nate Begeman2009-08-091-2/+3
| | | | | | | | In addition to being defined by the AltiVec PIM, this is also the vector initializer syntax used by OpenCL, so that vector literals are compatible with macro arguments. llvm-svn: 78535
* Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect thisJohn McCall2009-08-031-17/+19
| | | | | | | | 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
* Make functional-style casts emit correct messages, and fix a crash-on-invalid.Sebastian Redl2009-07-291-0/+4
| | | | llvm-svn: 77451
* Basic support for C++0x unicode types. Support for literals will follow in ↵Alisdair Meredith2009-07-141-0/+6
| | | | | | an incremental patch llvm-svn: 75622
* Keep track of the Expr used to describe the size of an array type,Douglas Gregor2009-07-061-1/+1
| | | | | | from Enea Zaffanella! llvm-svn: 74831
* Preliminary parsing and ASTs for template-ids that refer to functionDouglas Gregor2009-06-301-3/+26
| | | | | | | templates, such as make<int&>. These template-ids are only barely functional for function calls; much more to come. llvm-svn: 74563
* fix PR4452, a crash on invalid. The error recovery is still terrible in ↵Chris Lattner2009-06-261-3/+7
| | | | | | | | this case but at least we don't crash :) llvm-svn: 74264
* rearrange more code, this avoids a token lookahead for foo<Chris Lattner2009-06-261-44/+51
| | | | llvm-svn: 74261
* move some code around, no functionality change.Chris Lattner2009-06-261-32/+32
| | | | llvm-svn: 74260
* simplify some code.Chris Lattner2009-06-261-34/+35
| | | | llvm-svn: 74259
* Rework the way we track which declarations are "used" duringDouglas Gregor2009-06-221-4/+3
| | | | | | | | | | | | | | | | | | | | | compilation, and (hopefully) introduce RAII objects for changing the "potentially evaluated" state at all of the necessary places within Sema and Parser. Other changes: - Set the unevaluated/potentially-evaluated context appropriately during template instantiation. - We now recognize three different states while parsing or instantiating expressions: unevaluated, potentially evaluated, and potentially potentially evaluated (for C++'s typeid). - When we're in a potentially potentially-evaluated context, queue up MarkDeclarationReferenced calls in a stack. For C++ typeid expressions that are potentially evaluated, we will play back these MarkDeclarationReferenced calls when we exit the corresponding potentially potentially-evaluated context. - Non-type template arguments are now parsed as constant expressions, so they are not potentially-evaluated. llvm-svn: 73899
* Keep track of when declarations are "used" according to C andDouglas Gregor2009-06-191-0/+11
| | | | | | | | | | | | C++. This logic is required to trigger implicit instantiation of function templates and member functions of class templates, which will be implemented separately. This commit includes support for -Wunused-parameter, printing warnings for named parameters that are not used within a function/Objective-C method/block. Fixes <rdar://problem/6505209>. llvm-svn: 73797
* PR4122: Tweak the ambiguity handling to handle (S())() correctly. I've Eli Friedman2009-05-251-6/+11
| | | | | | left out handling for stuff like (S())++ for the moment. llvm-svn: 72394
* The disambiguation process for ambiguous paren expressions is not "side ↵Argyrios Kyrtzidis2009-05-221-47/+61
| | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud