summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Use ParseUnqualifiedId when parsing id-expressions. This eliminatesDouglas Gregor2009-11-031-1/+5
| | | | | | | | | | | 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
* simplify Sema::getTypeName a bit: if control gets out of the switch,Chris Lattner2009-10-251-1/+1
| | | | | | | IIDecl cannot be null. There is no need to check for both C++ mode and presence of CXXRecordDecl. ObjC interfaces can't have ScopeSpecs. llvm-svn: 85057
* In objc mode, every identifier in a cast expression was using doing aChris Lattner2009-10-251-18/+17
| | | | | | | | | | type looking using getTypeName() and every property access was using NextToken() to do lookahead to see if the identifier is followed by a '.'. Rearrange this code to not need lookahead and only do the type lookup if we have "identifier." in the token stream. Also improve a diagnostic a bit. llvm-svn: 85056
* Diagnose misuse of '.*' and '->*' operators during parseFariborz Jahanian2009-10-231-1/+12
| | | | | | instead of crashing in code gen. llvm-svn: 84968
* Parse a simple-template-id following a '~' when calling a destructor, e.g.,Douglas Gregor2009-10-191-7/+35
| | | | | | | | t->~T<A0, A1>() Fixes PR5213. llvm-svn: 84545
* Pass the right SourceLocation to ↵Anders Carlsson2009-10-131-2/+4
| | | | | | Actions.ActOnOverloadedOperatorReferenceExpr and Actions.ActOnConversionOperatorReferenceExpr. Update incomplete-call.cpp test. llvm-svn: 84026
* Implement code completion within a function call, triggered after theDouglas Gregor2009-09-221-2/+19
| | | | | | | | | | | | | | | | | | | | | opening parentheses and after each comma. We gather the set of visible overloaded functions, perform "partial" overloading based on the set of arguments that we have thus far, and return the still-viable results sorted by the likelihood that they will be the best candidate. Most of the changes in this patch are a refactoring of the overloading routines for a function call, since we needed to separate out the notion of building an overload set (common to code-completion and normal semantic analysis) and then what to do with that overload set. As part of this change, I've pushed explicit template arguments into a few more subroutines. There is still much more work to do in this area. Function templates won't be handled well (unless we happen to deduce all of the template arguments before we hit the completion point), nor will overloaded function-call operators or calls to member functions. llvm-svn: 82549
* Code completion for ordinary names when we're starting a declaration, ↵Douglas Gregor2009-09-211-0/+5
| | | | | | expression, or statement llvm-svn: 82481
* Initial implementation of a code-completion interface in Clang. InDouglas Gregor2009-09-171-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-52/+52
| | | | llvm-svn: 81346
* Initial stab at implement dependent member references to memberDouglas Gregor2009-09-091-2/+4
| | | | | | | | | | | | | 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
* If a destructor is referenced or a pseudo-destructor expression isDouglas Gregor2009-09-041-1/+2
| | | | | | | formed without a trailing '(', diagnose the error (these expressions must be immediately called), emit a fix-it hint, and fix the code. llvm-svn: 81015
* Rewrite of our handling of name lookup in C++ member access expressions, e.g.,Douglas Gregor2009-09-021-13/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud