summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/Parser.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Clean up ownership of 'AttributeList' objects in Parser. ApparentlyTed Kremenek2010-02-111-2/+2
| | | | | | | | | | | | | | | | | | | | | we would just leak them all over the place, with no clear ownership of these objects at all. AttributeList objects would get leaked on both error and non-error paths. Note: I introduced the usage of llvm::OwningPtr<AttributeList> to manage these objects, which is particularly useful for methods with multiple return sites. In at least one method I used them even when they weren't strictly necessary because it clarified the ownership semantics and made the code easier to read. Should the excessive 'take()' and 'reset()' calls become a performance issue we can always re-evaluate. Note+1: I believe I have not introduced any double-frees, but it would be nice for someone to review this. This fixes <rdar://problem/7635046>. llvm-svn: 95847
* When placing an annotation token over an existing annotation token, make ↵Sebastian Redl2010-02-081-1/+2
| | | | | | sure that the new token's range extends to the end of the old token. Assert that in AnnotateCachedTokens. Fixes PR6248. llvm-svn: 95555
* Fix assertion failure when parsing linkage specifications (PR5921),Douglas Gregor2010-02-071-1/+0
| | | | | | from Keir Mierle! llvm-svn: 95516
* First stage of adding AltiVec supportJohn Thompson2010-02-051-0/+5
| | | | llvm-svn: 95335
* Fixit to remove 'volatile' in file-scope 'asm volatile'.John McCall2010-01-251-1/+6
| | | | llvm-svn: 94466
* Warn on top-level 'asm volatile' (instead of misparsing it).John McCall2010-01-251-0/+5
| | | | | | "Fixes" rdar://problem/7574870 llvm-svn: 94458
* allow the HandlerComment callback to push tokens into theChris Lattner2010-01-181-1/+2
| | | | | | | preprocessor. This could be used by an OpenMP implementation or something. Patch by Abramo Bagnara! llvm-svn: 93795
* Whenever completing ordinary names for an Objective-C source, alsoDouglas Gregor2010-01-131-1/+3
| | | | | | | | | | | provide completions for @ keywords. Previously, we only provided @-completions after an @ was actually typed, which is useful but probably not the common case. Also, make sure a few Objective-C 2.0 completions only show up when Objective-C 2.0 support is enabled (the default). llvm-svn: 93354
* Reimplement constructor declarator parsing to cope with template-idsDouglas Gregor2010-01-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Improve code completion by introducing patterns for the various C andDouglas Gregor2010-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* Teach TryAnnotateTypeOrScopeToken to deal with already-annotatedJohn McCall2009-12-191-4/+9
| | | | | | | scope specifiers. Fix a tentative parsing bug that came up in LLVM. Incidentally fixes some random FIXMEs in an existing testcase. llvm-svn: 91734
* refactor the 'ColonIsSacred' argument to ParseOptionalCXXScopeSpecifierChris Lattner2009-12-101-1/+2
| | | | | | | to be a bool in Parser that is twiddled by the ColonProtectionRAIIObject class. No functionality change. llvm-svn: 91014
* rename ExtensionRAIIObject.h -> RAIIObjectsForParser.hChris Lattner2009-12-101-1/+1
| | | | llvm-svn: 91008
* Fixes a bogus error when declaring an extern "C" array.Fariborz Jahanian2009-12-091-3/+10
| | | | | | (fixes radar 7457109). llvm-svn: 90986
* fix a crash on invalid I found when working on something unrelated.Chris Lattner2009-12-071-1/+3
| | | | llvm-svn: 90729
* simplify logic.Chris Lattner2009-12-061-6/+7
| | | | llvm-svn: 90712
* remove some extraneous syntax: sourceloc implicitly converts to sourcerange.Chris Lattner2009-12-061-1/+1
| | | | llvm-svn: 90710
* Added rudimentary C++0x attribute support.Alexis Hunt2009-11-211-8/+19
| | | | | | | | | | | | | | 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
* Improve parsing of template arguments to lay the foundation forDouglas Gregor2009-11-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* Change our basic strategy for avoiding deprecation warnings when the decl useJohn McCall2009-11-041-2/+13
| | | | | | | | | | | | appears in a deprecated context. In the new strategy, we emit the warnings as usual unless we're currently parsing a declaration, where "declaration" is restricted to mean a decl group or a few special cases in Objective C. If we *are* parsing a declaration, we queue up the deprecation warnings until the declaration has been completely parsed, and then emit them only if the decl is not deprecated. We also standardize the bookkeeping for deprecation so as to avoid special cases. llvm-svn: 85998
* Implement support for parsing dependent template-ids that refer toDouglas Gregor2009-11-041-2/+5
| | | | | | | | overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
* Parsing and semantic analysis for template-ids that name overloadedDouglas Gregor2009-11-031-2/+3
| | | | | | | | | | | | 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
* Silence a warning by giving Parser::FieldCallback a virtual destructor, andJohn McCall2009-11-031-0/+7
| | | | | | anchor the vtable to Parser.cpp for good measure. llvm-svn: 85927
* Reorganize the parsing of decl groups / function definitions so thatJohn McCall2009-11-031-48/+2
| | | | | | | declarators are parsed primarily within a single function (at least for these cases). Remove some excess diagnostics arising during parse failures. llvm-svn: 85924
* Don't crash when dumping pretty stack traces, if the current tok is anDaniel Dunbar2009-10-171-1/+4
| | | | | | | | annotation token. - I'm not sure what the best thing to print is, for now we just print the token location and 'at annotation token'. llvm-svn: 84312
* Code completion for ordinary names when we're starting a declaration, ↵Douglas Gregor2009-09-211-0/+4
| | | | | | expression, or statement llvm-svn: 82481
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-46/+46
| | | | llvm-svn: 81346
* Parse extern templates, pass that information all the way to Sema,Douglas Gregor2009-09-041-0/+15
| | | | | | then drop it on the floor. llvm-svn: 80989
* Rewrite of our handling of name lookup in C++ member access expressions, e.g.,Douglas Gregor2009-09-021-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Improve support for out-of-line definitions of nested templates andDouglas Gregor2009-08-251-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Eliminate a GCC warningDouglas Gregor2009-08-251-1/+1
| | | | llvm-svn: 79962
* Keep track of the template parameter depth properly when we haveDouglas Gregor2009-08-241-1/+1
| | | | | | | | | | member templates declared inside other templates. This allows us to match out-of-line definitions of member function templates within class templates to the declarations within the class template. We still can't handle out-of-line definitions for member class templates, however. llvm-svn: 79955
* Top-level semicolons are allowed in C++0x. Fixes PR4755.Douglas Gregor2009-08-241-3/+8
| | | | llvm-svn: 79912
* Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect thisJohn McCall2009-08-031-3/+5
| | | | | | | | 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
* sp.John McCall2009-07-311-1/+1
| | | | llvm-svn: 77656
* Patch to accomodate Doug's comment on defaultFariborz Jahanian2009-07-211-1/+1
| | | | | | destruction of base/members for each destructor AST. llvm-svn: 76663
* Added ASTs to destructor decl AST for default destruction of object'sFariborz Jahanian2009-07-151-1/+1
| | | | | | base/members. llvm-svn: 75849
* Build AST for default ctor-initializer when constructor hasFariborz Jahanian2009-07-141-0/+2
| | | | | | out of line definition. llvm-svn: 75668
* Add support for retrieving the Doxygen comment associated with a givenDouglas Gregor2009-07-021-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | declaration in the AST. The new ASTContext::getCommentForDecl function searches for a comment that is attached to the given declaration, and returns that comment, which may be composed of several comment blocks. Comments are always available in an AST. However, to avoid harming performance, we don't actually parse the comments. Rather, we keep the source ranges of all of the comments within a large, sorted vector, then lazily extract comments via a binary search in that vector only when needed (which never occurs in a "normal" compile). Comments are written to a precompiled header/AST file as a blob of source ranges. That blob is only lazily loaded when one requests a comment for a declaration (this never occurs in a "normal" compile). The indexer testbed now supports comment extraction. When the -point-at location points to a declaration with a Doxygen-style comment, the indexer testbed prints the associated comment block(s). See test/Index/comments.c for an example. Some notes: - We don't actually attempt to parse the comment blocks themselves, beyond identifying them as Doxygen comment blocks to associate them with a declaration. - We won't find comment blocks that aren't adjacent to the declaration, because we start our search based on the location of the declaration. - We don't go through the necessary hops to find, for example, whether some redeclaration of a declaration has comments when our current declaration does not. Similarly, we don't attempt to associate a \param Foo marker in a function body comment with the parameter named Foo (although that is certainly possible). - Verification of my "no performance impact" claims is still "to be done". llvm-svn: 74704
* Fix screwup with my previous patch which broke tests. (The patch is Eli Friedman2009-06-271-1/+1
| | | | | | | making sure we return true when annotating a function template with explicit template arguments, but not when we don't annotate anything.) llvm-svn: 74383
* Fix a crash with constructs like x<false>() in C++. No testcase because Eli Friedman2009-06-271-1/+1
| | | | | | it doesn't actually work yet; we just error out a bit more gracefully. llvm-svn: 74381
* fix PR4452, a crash on invalid. The error recovery is still terrible in ↵Chris Lattner2009-06-261-3/+10
| | | | | | | | this case but at least we don't crash :) llvm-svn: 74264
* Make sure that the template parameter lists get from the parser down to ↵Douglas Gregor2009-06-241-2/+9
| | | | | | ActOnFunctionDeclarator for function template definitions llvm-svn: 74040
* Add parser support for #pragma weak.Eli Friedman2009-06-051-0/+6
| | | | llvm-svn: 72907
* Reimplement much of the way that we track nested classes in theDouglas Gregor2009-05-271-3/+0
| | | | | | | | | | | | | parser. Rather than placing all of the delayed member function declarations and inline definitions into a single bucket corresponding to the top-level class, we instead mirror the nesting structure of the nested classes and place the delayed member functions into their appropriate place. Then, when we actually parse the delayed member function declarations, set up the scope stack the same way as it was when we originally saw the declaration, so that we can find, e.g., template parameters that are in scope. llvm-svn: 72502
* Implement parsing for explicit instantiations of class templates, e.g.,Douglas Gregor2009-05-121-1/+1
| | | | | | | | | template class X<int>; This also cleans up the propagation of template information through declaration parsing, which is used to improve some diagnostics. llvm-svn: 71608
* Parser::ParseDeclarationOrFunctionDefinition no longer needs to acceptDouglas Gregor2009-05-121-4/+2
| | | | | | template parameters. llvm-svn: 71598
* Refactor the parsing of declarations so that template declarations canDouglas Gregor2009-05-121-15/+26
| | | | | | | | | | parse just a single declaration and provide a reasonable diagnostic when the "only one declarator per template declaration" rule is violated. This eliminates some ugly, ugly hackery where we used to require thatn the layout of a DeclGroup of a single element be the same as the layout of a single declaration. llvm-svn: 71596
* Implement function-try-blocks. However, there's a very subtle bug that I ↵Sebastian Redl2009-04-261-5/+8
| | | | | | can't track down. llvm-svn: 70155
* fix a FIXME, providing accurate source range info for DeclStmt's. The endChris Lattner2009-04-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of the range is now the ';' location. For something like this: $ cat t2.c #define bool int void f(int x, int y) { bool b = !x && y; } We used to produce: $ clang-cc t2.c -ast-dump typedef char *__builtin_va_list; void f(int x, int y) (CompoundStmt 0x2201f10 <t2.c:3:22, line:5:1> (DeclStmt 0x2201ef0 <line:2:14> <---- 0x2201a20 "int b = (BinaryOperator 0x2201ed0 <line:4:10, col:16> 'int' '&&' (UnaryOperator 0x2201e90 <col:10, col:11> 'int' prefix '!' (DeclRefExpr 0x2201c90 <col:11> 'int' ParmVar='x' 0x2201a50)) (DeclRefExpr 0x2201eb0 <col:16> 'int' ParmVar='y' 0x2201e10))") Now we produce: $ clang-cc t2.c -ast-dump typedef char *__builtin_va_list; void f(int x, int y) (CompoundStmt 0x2201f10 <t2.c:3:22, line:5:1> (DeclStmt 0x2201ef0 <line:2:14, line:4:17> <------ 0x2201a20 "int b = (BinaryOperator 0x2201ed0 <col:10, col:16> 'int' '&&' (UnaryOperator 0x2201e90 <col:10, col:11> 'int' prefix '!' (DeclRefExpr 0x2201c90 <col:11> 'int' ParmVar='x' 0x2201a50)) (DeclRefExpr 0x2201eb0 <col:16> 'int' ParmVar='y' 0x2201e10))") llvm-svn: 68288
OpenPOWER on IntegriCloud