summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Implement C++0x user-defined string literals.Alexis Hunt2010-08-291-1/+2
| | | | | | | | | | The extra data stored on user-defined literal Tokens is stored in extra allocated memory, which is managed by the PreprocessorLexer because there isn't a better place to put it that makes sure it gets deallocated, but only after it's used up. My testing has shown no significant slowdown as a result, but independent testing would be appreciated. llvm-svn: 112458
* Propagate whether an id-expression is the immediate argument ofJohn McCall2010-08-271-1/+5
| | | | | | | | | | | | | | | | | | | an '&' expression from the second caller of ActOnIdExpression. Teach template argument deduction that an overloaded id-expression doesn't give a valid type for deduction purposes to a non-static member function unless the expression has the correct syntactic form. Teach ActOnIdExpression that it shouldn't try to create implicit member expressions for '&function', because this isn't a permitted form of use for member functions. Teach CheckAddressOfOperand to diagnose these more carefully. Some of these cases aren't reachable right now because earlier diagnostics interrupt them. llvm-svn: 112258
* One who seeks knowledge learns something new every day.John McCall2010-08-261-11/+11
| | | | | | | | | 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
* Preserve invalidity of typeof operands in C++.John McCall2010-08-241-1/+2
| | | | llvm-svn: 111999
* OwningExprResult -> ExprResult. This patch brought to you byJohn McCall2010-08-241-44/+44
| | | | | | | M-x query-replace-regexp \(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result llvm-svn: 111903
* Abstract out passing around types and kill off ActionBase.John McCall2010-08-241-15/+15
| | | | llvm-svn: 111901
* Kill off ExprArg (now just Expr*) and StmtArg (now just Stmt*).John McCall2010-08-231-68/+59
| | | | llvm-svn: 111863
* Sundry incremental steps towards killing off Action.John McCall2010-08-231-13/+14
| | | | llvm-svn: 111795
* Another step in the process of making the parser depend on Sema:John McCall2010-08-201-3/+3
| | | | | | | | | - 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
* Once code completion has completed, pass a "completion context" on toDouglas Gregor2010-08-111-2/+2
| | | | | | | the code-completion consumer. The consumer can use this information to augument, filter, or display the code-completion results. llvm-svn: 110858
* The pre-increment/pre-decrement grammar in C++ differs from that in C,Douglas Gregor2010-08-061-4/+8
| | | | | | | but we were parsing the C grammar. Handle the C++ grammar appropriately. Fixes PR7794. llvm-svn: 110445
* The grammar for GNU typeof in C requires an expression to beDouglas Gregor2010-07-281-4/+7
| | | | | | | | | | | | | parenthesized, unlike in C++, e.g., C has: typeof ( expression) C++ has: typeof unary-expression So, once we've parsed a parenthesized expression after typeof, we should only go on to parse the postfix expression suffix if we're in C++. Fixes <rdar://problem/8237491>. llvm-svn: 109606
* tidy up comment.Chris Lattner2010-07-191-2/+1
| | | | llvm-svn: 108676
* Move the "current scope" state from the Parser into Action. ThisDouglas Gregor2010-07-021-31/+31
| | | | | | | | | | | | | | 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
* Minor tweaks on doug's objc recovery patch: the callerChris Lattner2010-05-311-1/+8
| | | | | | | | | | | | of isSimpleObjCMessageExpression checks the language, so change a dynamic check into an assert. isSimpleObjCMessageExpression is expensive, so only do it in the common case when it is likely to matter: when the [ of the postfix expr starts on a new line. This should avoid doing lookahead for every array expression. llvm-svn: 105229
* When we see the a '[' in a postfix expression in Objective-C, performDouglas Gregor2010-05-311-0/+3
| | | | | | | | | | | | | | | | | | | a simple, quick check to determine whether the expression starting with '[' can only be an Objective-C message send. If so, don't parse it as an array subscript expression. This improves recovery for, e.g., [a method1] [a method2] so that we now produce t.m:10:13: error: expected ';' after expression [a method] ^ instead of some mess about expecting ']'. llvm-svn: 105221
* Improve parser recovery when we try to parse a call expression but theDouglas Gregor2010-05-301-1/+8
| | | | | | | called function itself is invalid (e.g., because of a semantic error referring to that declaration). Fixes <rdar://problem/8044142>. llvm-svn: 105175
* Teach code completion to adjust its completion priorities based on theDouglas Gregor2010-05-301-0/+8
| | | | | | | | | type that we expect to see at a given point in the grammar, e.g., when initializing a variable, returning a result, or calling a function. We don't prune the candidate set at all, just adjust priorities to favor things that should type-check, using an ultra-simplified type system. llvm-svn: 105128
* When we've parsed a nested-name-specifier in a member accessDouglas Gregor2010-05-271-0/+2
| | | | | | | expression, "forget" about the object type; only the nested-name-specifier matters for name lookup purposes. Fixes PR7239. llvm-svn: 104834
* Improve code completion in failure cases in two ways:Douglas Gregor2010-05-251-5/+5
| | | | | | | | | | | 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 the fixit for the missing : error when parsing ?:. WhenChris Lattner2010-05-241-1/+22
| | | | | | | | | | | | | | | | | | | | there are already two spaces before the token where the : was expected, put the : in between the spaces. This means we get it right in both of these cases: t.c:2:17: error: expected ':' return a ? b c; ^ : t.c:3:16: error: expected ':' return a ? b c; ^ : In the later case, the diagnostic says to insert ": ", in the former case it says to insert ":" between the spaces. This fixes rdar://8007231 llvm-svn: 104569
* When parsing a cast-expression that starts with a scope annotation,Douglas Gregor2010-04-231-0/+8
| | | | | | | try to annotate as a type first to determine whether we have a functional-style cast. Patch by Eli Friedman, fixes PR6830. llvm-svn: 102161
* Implement parsing for message sends in Objective-C++. Message sends inDouglas Gregor2010-04-211-30/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Rework the Parser-Sema interaction for Objective-C messageDouglas Gregor2010-04-211-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sends. Major changes include: - Expanded the interface from two actions (ActOnInstanceMessage, ActOnClassMessage), where ActOnClassMessage also handled sends to "super" by checking whether the identifier was "super", to three actions (ActOnInstanceMessage, ActOnClassMessage, ActOnSuperMessage). Code completion has the same changes. - The parser now resolves the type to which we are sending a class message, so ActOnClassMessage now accepts a TypeTy* (rather than an IdentifierInfo *). This opens the door to more interesting types (for Objective-C++ support). - Split ActOnInstanceMessage and ActOnClassMessage into parser action functions (with their original names) and semantic functions (BuildInstanceMessage and BuildClassMessage, respectively). At present, this split is onyl used by ActOnSuperMessage, which decides which kind of super message it has and forwards to the appropriate Build*Message. In the future, Build*Message will be used by template instantiation. - Use getObjCMessageKind() within the disambiguation of Objective-C message sends vs. array designators. Two notes about substandard bits in this patch: - There is some redundancy in the code in ParseObjCMessageExpr and ParseInitializerWithPotentialDesignator; this will be addressed shortly by centralizing the mapping from identifiers to type names for the message receiver. - There is some #if 0'd code that won't likely ever be used---it handles the use of 'super' in methods whose class does not have a superclass---but could be used to model GCC's behavior more closely. This code will die in my next check-in, but I want it in Subversion. llvm-svn: 102021
* fix the ?: fixit that ted added to recover properly.Chris Lattner2010-04-201-5/+5
| | | | llvm-svn: 101943
* Add fixit hint for missing ':' in ternary expressions.Ted Kremenek2010-04-121-1/+2
| | | | llvm-svn: 101073
* tighten the check for cast of super to avoid rejecting valid code,Chris Lattner2010-04-121-1/+2
| | | | | | rdar://7853261 llvm-svn: 101048
* fix a rejects-valid bug that I introduced, pointed out Chris Lattner2010-04-121-5/+5
| | | | | | by David Chisnall llvm-svn: 101024
* use pointer comparison instead of isStrChris Lattner2010-04-121-3/+2
| | | | llvm-svn: 101022
* fix a rejects-valid testcase involving super that I dreamt up.Chris Lattner2010-04-121-1/+3
| | | | | | | This also fixes cases where super is used in a block in a method which isn't valid. llvm-svn: 101021
* fix PR6811 by not parsing 'super' as a magic expression inChris Lattner2010-04-111-4/+11
| | | | | | | | | | | | | LookupInObjCMethod. Doing so allows all sorts of invalid code to slip through to codegen. This patch does not change the AST representation of super, though that would now be a natural thing to do since it can only be in the receiver position and in the base of a ObjCPropertyRefExpr. There are still several ugly areas handling super in the parser, but this is definitely a step in the right direction. llvm-svn: 100959
* Perform code-completion within ParseCastExpression, which handles,Douglas Gregor2010-04-061-1/+6
| | | | | | e.g., the right-hand side of binary expressions. llvm-svn: 100526
* Fix an assertion-on-error during tentative constructor parsing byJohn McCall2010-02-261-1/+5
| | | | | | | | | | 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-1/+1
| | | | | | | | | 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
* Rework parsing of pseudo-destructor expressions and explicitDouglas Gregor2010-02-241-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | 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
* When we're parsing an expression that may have looked like aDouglas Gregor2010-02-051-2/+38
| | | | | | | | | declaration, we can end up with template-id annotation tokens for types that have not been converted into type annotation tokens. When this is the case, translate the template-id into a type and parse as an expression. llvm-svn: 95404
* First stage of adding AltiVec supportJohn Thompson2010-02-051-0/+1
| | | | llvm-svn: 95335
* Improve code completion by introducing patterns for the various C andDouglas Gregor2010-01-101-5/+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
* When parsing an identifier as an expression in C++, only try to annotate itJohn McCall2010-01-071-3/+11
| | | | | | | | | | as a type or scope token if the next token requires it. This eliminates a lot of redundant lookups in C++, but there's room for improvement; a better solution would do a single lookup whose kind and results would be passed through the parser. llvm-svn: 92930
* If we enter parens, colons can become un-sacred, allowing us to emitChris Lattner2009-12-101-3/+9
| | | | | | a better diagnostic in the second example. llvm-svn: 91040
* fix a more evil case of : / :: confusion arising in ?:.Chris Lattner2009-12-101-0/+3
| | | | llvm-svn: 91039
* rename ExtensionRAIIObject.h -> RAIIObjectsForParser.hChris Lattner2009-12-101-1/+1
| | | | llvm-svn: 91008
* Introduce the notion of literal types, as specified in C++0x.Sebastian Redl2009-12-031-0/+1
| | | | llvm-svn: 90361
* Some fancy footwork to move the decision on how Fariborz Jahanian2009-11-251-11/+11
| | | | | | to build casted expression-list AST to Sema. llvm-svn: 89827
* Fix a recent regression probably caused by addition of altivec-styleFariborz Jahanian2009-11-231-1/+2
| | | | | | type-casts in the parser. llvm-svn: 89691
* Added rudimentary C++0x attribute support.Alexis Hunt2009-11-211-4/+4
| | | | | | | | | | | | | | 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
* This patch fixes a bug in misdiagnosing correctFariborz Jahanian2009-11-181-11/+0
| | | | | | use of pointer to data member. llvm-svn: 89251
* Remove a bunch of #if 0'd code made irrelevant by the latest ↵Douglas Gregor2009-11-031-106/+0
| | | | | | ParseUnqualifiedId changes llvm-svn: 85938
* Replace the code that parses member access expressions after "." orDouglas Gregor2009-11-031-0/+16
| | | | | | | | | | | | "->" 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
OpenPOWER on IntegriCloud