summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExprCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Some minor comments modifications.Argyrios Kyrtzidis2009-05-221-2/+2
| | | | | | There are no unnecessary action calls period (courtesy of the annotation scheme) and too many 'this means'.. llvm-svn: 72263
* Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate ↵Argyrios Kyrtzidis2009-05-221-0/+107
| | | | | | | | | | | | | | 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
* Remove ParseSimpleParenExpression.Argyrios Kyrtzidis2009-05-221-3/+12
| | | | | | | | 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
* Merge the ASTVector and ASTOwningVector templates, since they offeredDouglas Gregor2009-05-211-1/+0
| | | | | | | | redundant functionality. The result (ASTOwningVector) lives in clang/Parse/Ownership.h and is used by both the parser and semantic analysis. No intended functionality change. llvm-svn: 72214
* Use v.data() instead of &v[0] when SmallVector v might be empty.Jay Foad2009-05-211-1/+1
| | | | llvm-svn: 72210
* Implement explicit instantiations of member classes of class templates, e.g.,Douglas Gregor2009-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | template<typename T> struct X { struct Inner; }; template struct X<int>::Inner; This change is larger than it looks because it also fixes some a problem with nested-name-specifiers and tags. We weren't requiring the DeclContext associated with the scope specifier of a tag to be complete. Therefore, when looking for something like "struct X<int>::Inner", we weren't instantiating X<int>. This, naturally, uncovered a problem with member pointers, where we were requiring the left-hand side of a member pointer access expression (e.g., x->*) to be a complete type. However, this is wrong: the semantics of this expression does not require a complete type (EDG agrees). Stuart vouched for me. Blame him. llvm-svn: 71756
* This is a pretty big cleanup for how invalid decl/type are handle.Chris Lattner2009-04-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud