aboutsummaryrefslogtreecommitdiff
path: root/lib/Parse/ParseExprCXX.cpp
AgeCommit message (Collapse)Author
2009-11-29Add DeclarationName support for C++0x operator literals. They should now work asSean Hunt
function names outside of templates - they'll probably cause some damage there as they're largely untested. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90064 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-28Fix test and handle IK_LiteralOperatorId in a few more places.Sean Hunt
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90030 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-28Add Parser support for C++0x literal operators ('operator "" i').Sean Hunt
DeclarationName can't handle them yet, so right now Parser just errors out on them. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90027 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-25Eliminate CXXConditionDeclExpr with extreme prejudice.Douglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89817 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-22If a C++ qualified id is followed by a postfix suffix, it is never the directJohn McCall
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89578 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-21Added rudimentary C++0x attribute support.Sean Hunt
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) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89543 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-20Cope with extraneous "template" keyword when providing an out-of-lineDouglas Gregor
definition of a member template (or a member thereof). Fixes PR5566. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89512 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-20Implement C++ [basic.lookup.classref]p3, which states how the typeDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89493 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-11Fix speculative parsing of dependent template names inDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86841 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-10Improve parsing of template arguments to lay the foundation forDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86708 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-06Improve recovery when we fail to parse the operand of a C++ named cast. ↵Douglas Gregor
Fixes PR5210 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86234 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-04Eliminate the "old" ways of parsing operator-function-ids andDouglas Gregor
conversion-function-ids; all clients have moved on to ParseUnqualifiedId. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86028 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-04Implement support for parsing dependent template-ids that refer toDouglas Gregor
overloaded operators, e.g., p->template operator+<T>() git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85989 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-03Parsing and semantic analysis for template-ids that name overloadedDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85966 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-03Tweak some comments about unqualified-id and id-expression parsing. No ↵Douglas Gregor
functionality change git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85942 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-03Replace the code that parses member access expressions after "." orDouglas Gregor
"->" 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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85930 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-03Use ParseUnqualifiedId when parsing id-expressions. This eliminatesDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85904 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-03Introduce a new class, UnqualifiedId, that provides a parsedDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85851 91177308-0d34-0410-b5e6-96231b3b80d8
2009-10-22When building and instantiating a template-id reference expression, such asDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84869 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-18C++ code completion after the "operator" keyword. Provide overloadedDouglas Gregor
operators, type specifiers, type names, and nested-name-specifiers. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82264 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-17Initial implementation of a code-completion interface in Clang. InDouglas Gregor
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". git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82166 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-09Remove tabs, and whitespace cleanups.Mike Stump
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81346 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-09Initial stab at implement dependent member references to memberDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81300 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-02Rewrite of our handling of name lookup in C++ member access expressions, e.g.,Douglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80843 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-29Fix a couple issues with parsing invalid nested-name-specifiers.Eli Friedman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80421 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-25Improve support for out-of-line definitions of nested templates andDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80044 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-10Take 2 on AltiVec-style vector initializers. Nate Begeman
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78621 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-10Revert r78535, it is causing a number of failures to build projects.Daniel Dunbar
--- 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78551 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-09AltiVec-style vector initializer syntax, vec4 a = (vec4)(a, b, c, d);Nate Begeman
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78535 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-03Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect thisJohn McCall
elsewhere. Very slightly decouples DeclSpec users from knowing the exact diagnostics to report, and makes it easier to provide different diagnostics in some places. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77990 91177308-0d34-0410-b5e6-96231b3b80d8
2009-07-29Make functional-style casts emit correct messages, and fix a crash-on-invalid.Sebastian Redl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77451 91177308-0d34-0410-b5e6-96231b3b80d8
2009-07-14Basic support for C++0x unicode types. Support for literals will follow in ↵Alisdair Meredith
an incremental patch git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@75622 91177308-0d34-0410-b5e6-96231b3b80d8
2009-07-06Keep track of the Expr used to describe the size of an array type,Douglas Gregor
from Enea Zaffanella! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74831 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-30Preliminary parsing and ASTs for template-ids that refer to functionDouglas Gregor
templates, such as make<int&>. These template-ids are only barely functional for function calls; much more to come. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74563 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-26fix PR4452, a crash on invalid. The error recovery is still terrible in ↵Chris Lattner
this case but at least we don't crash :) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74264 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-26rearrange more code, this avoids a token lookahead for foo<Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74261 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-26move some code around, no functionality change.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74260 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-26simplify some code.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74259 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-22Rework the way we track which declarations are "used" duringDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73899 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-19Keep track of when declarations are "used" according to C andDouglas Gregor
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>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73797 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-25PR4122: Tweak the ambiguity handling to handle (S())() correctly. I've Eli Friedman
left out handling for stuff like (S())++ for the moment. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72394 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-22The disambiguation process for ambiguous paren expressions is not "side ↵Argyrios Kyrtzidis
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72279 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-22Some minor comments modifications.Argyrios Kyrtzidis
There are no unnecessary action calls period (courtesy of the annotation scheme) and too many 'this means'.. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72263 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-22Handle correctly a very ugly part of the C++ syntax. We cannot disambiguate ↵Argyrios Kyrtzidis
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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72260 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-22Remove ParseSimpleParenExpression.Argyrios Kyrtzidis
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72257 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-21Merge the ASTVector and ASTOwningVector templates, since they offeredDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72214 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-21Use v.data() instead of &v[0] when SmallVector v might be empty.Jay Foad
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72210 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-14Implement explicit instantiations of member classes of class templates, e.g.,Douglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71756 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-25This is a pretty big cleanup for how invalid decl/type are handle.Chris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70020 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-01Add code modification hints to various parsing-related diagnostics.Douglas Gregor
Plus, reword a extension warnings to avoid talking about "ISO C" when the extension might also be available in C++ or C++0x. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68257 91177308-0d34-0410-b5e6-96231b3b80d8