summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse
Commit message (Collapse)AuthorAgeFilesLines
* Clean up ownership of 'AttributeList' objects in Parser. ApparentlyTed Kremenek2010-02-115-46/+83
| | | | | | | | | | | | | | | | | | | | | 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-082-2/+3
| | | | | | 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-072-1/+2
| | | | | | from Keir Mierle! llvm-svn: 95516
* Add attributes to namespace decls.Anders Carlsson2010-02-071-2/+2
| | | | llvm-svn: 95510
* 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
* Revert the unused TST_pixel entry from r95335 as it is not listed in the SemaChandler Carruth2010-02-051-1/+0
| | | | | | switch, triggering warnings. llvm-svn: 95381
* First stage of adding AltiVec supportJohn Thompson2010-02-055-3/+85
| | | | llvm-svn: 95335
* In some contexts, type declarations cannot occur. Pass this information down ↵Sebastian Redl2010-02-033-9/+22
| | | | | | to ParseClassSpecifier, to make its decision easier. Fixes PR6200. llvm-svn: 95255
* Declarators can have grouping parens. This fixes rdar://7608537.Chris Lattner2010-02-031-0/+1
| | | | llvm-svn: 95246
* fix PR6216Chris Lattner2010-02-031-0/+1
| | | | llvm-svn: 95185
* Simplify setting of DeclContext for @catch variableFariborz Jahanian2010-02-031-0/+1
| | | | | | (per Doug's comment). llvm-svn: 95169
* Fix DeclContext of an objective-c @catch variableFariborz Jahanian2010-02-031-0/+1
| | | | | | declaration. Fixes radar 7590273. llvm-svn: 95164
* the declspec of a declaration can have storage-class specifiers,Chris Lattner2010-02-021-7/+18
| | | | | | | | | type qualifiers and type specifiers in any order. For example, this is valid: struct x {...} typedef y; This fixes PR6208. llvm-svn: 95094
* Implement PR6180, substantially improving the diagnostics we get fromChris Lattner2010-02-021-1/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | forgetting a ';' at the end of a struct. For something like: class c { } void foo() {} we now produce: t.cc:3:2: error: expected ';' after class } ^ ; instead of: t.cc:4:1: error: cannot combine with previous 'class' declaration specifier void foo() {} ^ t.cc:2:7: error: 'class c' can not be defined in the result type of a function class c { ^ GCC produces: t.cc:4: error: new types may not be defined in a return type t.cc:4: note: (perhaps a semicolon is missing after the definition of ‘c’) t.cc:4: error: two or more data types in declaration of ‘foo’ I *think* I got the follow set right, but if I forgot anything, we'll start getting spurious "expected ';' after class" errors, let me know if you see any. llvm-svn: 95042
* improve diagnostics for C++ struct ; issues. Before:Chris Lattner2010-02-021-12/+8
| | | | | | | | | | | | | | | | | | | | | | t.cc:4:3: error: expected ';' at end of declaration list int y; ^ t.cc:6:1: error: expected ';' at end of declaration list }; ^ After: t.cc:3:8: error: expected ';' at end of declaration list int x ^ ; t.cc:5:8: error: expected ';' at end of declaration list int z ^ ; llvm-svn: 95039
* improve diagnostics on missing ; in a struct. Before:Chris Lattner2010-02-021-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | t.c:4:3: error: expected ';' at end of declaration list int y; ^ t.c:4:8: warning: extra ';' inside a struct or union int y; ^ t.c:6:1: warning: expected ';' at end of declaration list }; ^ After: t.c:3:8: error: expected ';' at end of declaration list int x // expected-error {{expected ';' at end of declaration list}} ^ ; t.c:5:8: warning: expected ';' at end of declaration list int z ^ ; llvm-svn: 95038
* Rework base and member initialization in constructors, with severalDouglas Gregor2010-01-311-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (necessarily simultaneous) changes: - CXXBaseOrMemberInitializer now contains only a single initializer rather than a set of initialiation arguments + a constructor. The single initializer covers all aspects of initialization, including constructor calls as necessary but also cleanup of temporaries created by the initializer (which we never handled before!). - Rework + simplify code generation for CXXBaseOrMemberInitializers, since we can now just emit the initializer as an initializer. - Switched base and member initialization over to the new initialization code (InitializationSequence), so that it - Improved diagnostics for the new initialization code when initializing bases and members, to match the diagnostics produced by the previous (special-purpose) code. - Simplify the representation of type-checked constructor initializers in templates; instead of keeping the fully-type-checked AST, which is rather hard to undo at template instantiation time, throw away the type-checked AST and store the raw expressions in the AST. This simplifies instantiation, but loses a little but of information in the AST. - When type-checking implicit base or member initializers within a dependent context, don't add the generated initializers into the AST, because they'll look like they were explicit. - Record in CXXConstructExpr when the constructor call is to initialize a base class, so that CodeGen does not have to infer it from context. This ensures that we call the right kind of constructor. There are also a few "opportunity" fixes here that were needed to not regress, for example: - Diagnose default-initialization of a const-qualified class that does not have a user-declared default constructor. We had this diagnostic specifically for bases and members, but missed it for variables. That's fixed now. - When defining the implicit constructors, destructor, and copy-assignment operator, set the CurContext to that constructor when we're defining the body. llvm-svn: 94952
* Use IdentifierInfo * instead of std::string for the AsmStmt names.Anders Carlsson2010-01-301-8/+7
| | | | llvm-svn: 94925
* 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
* Move the type specifier location for elaborated-type-specifiers fromDouglas Gregor2010-01-252-3/+9
| | | | | | | the tag kind (union, struct, class, enum) over to the name of the tag, if there is a name, since most clients want to point at the name. llvm-svn: 94424
* -fno-rtti is now the default.Chris Lattner2010-01-241-1/+0
| | | | llvm-svn: 94379
* fix PR6034, a crash on invalid where the switch stack would get Chris Lattner2010-01-241-8/+8
| | | | | | unbalanced. llvm-svn: 94347
* Implement elementary access control.John McCall2010-01-231-1/+1
| | | | llvm-svn: 94268
* 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
* Improve source-location information for builtin TypeLocs, from EneaDouglas Gregor2010-01-181-0/+19
| | | | | | Zaffanella (with a couple of my tweaks). llvm-svn: 93733
* While determining when to parse inline member functions of a class,Douglas Gregor2010-01-161-8/+28
| | | | | | | | | | | | distinguish between nested classes (whose member functions cannot be parsed until the innermost non-nested class is complete) and local classes (that are defined within a function but are not necessarily nested). The upshot of this change, which fixes PR5764, is that the bodies of member functions of local (non-nested) classes need to be parsed when the local class is complete (and no later), since they may refer to function-local static variables, typedefs, enums, etc. llvm-svn: 93653
* Keep track of the source locations for each protocol reference inDouglas Gregor2010-01-162-0/+4
| | | | | | | | Objective-C classes, protocol definitions, forward protocol declarations, and categories. This information isn't actually used yet; that's coming next. llvm-svn: 93636
* Code-completion for @public, @protected, @private, @package.Douglas Gregor2010-01-131-0/+12
| | | | llvm-svn: 93361
* Whenever completing ordinary names for an Objective-C source, alsoDouglas Gregor2010-01-133-2/+14
| | | | | | | | | | | 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
* Add type source information for both kinds of typeof types.John McCall2010-01-131-0/+4
| | | | | | Patch by Enea Zaffanella. llvm-svn: 93344
* Reimplement constructor declarator parsing to cope with template-idsDouglas Gregor2010-01-135-24/+189
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 recovery for template-ids whose template-name doesn't actuallyDouglas Gregor2010-01-121-6/+45
| | | | | | | | | | | | | | | | | | | | | | name a template, when they occur in a base-specifier. This is one of the (few) places where we know for sure that an identifier followed by a '<' must be a template name, so we can diagnose and recover well: test/SemaTemplate/dependent-base-classes.cpp:9:16: error: missing 'template' keyword prior to dependent template name 'T::apply' struct X1 : T::apply<U> { }; // expected-error{{missing 'template' ... ^ template test/SemaTemplate/dependent-base-classes.cpp:12:13: error: unknown template name 'vector' struct X2 : vector<T> { }; // expected-error{{unknown template name 'vector'}} ^ 2 diagnostics generated. llvm-svn: 93257
* Parse dependent template-ids in base clauses and memberDouglas Gregor2010-01-121-3/+4
| | | | | | | | | initializers. This isn't actually in the C++ grammar (in any version), but that's clearly an oversight: both GCC and EDG support this syntax, and it's used within Boost code. I'll file a core issue proposing precisely the change made here. Fixes PR6008. llvm-svn: 93243
* Eliminate an embarrassing performance regression in C/ObjC, where weDouglas Gregor2010-01-111-1/+9
| | | | | | | | | | were performing name lookup for template names in C/ObjC and always finding nothing. Turn off such lookup unless we're in C++ mode, along with the check that determines whether the given identifier is a "current class name", and assert that we don't make this mistake again. llvm-svn: 93207
* Improve code completion by introducing patterns for the various C andDouglas Gregor2010-01-105-9/+23
| | | | | | | | | | | | | | | | | | | | | | 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
* Change ObjCContainerDecl to contain the entire range for the '@end'Ted Kremenek2010-01-071-8/+11
| | | | | | | | | | | piece of the declaration. The '@' and the 'end' are separate tokens, and require two SourceLocations to accurately track. This change was motivated because ObjCContainerDecl::getSourceRange() would previously not return the entire range of the declaration (the 'end' would be left off). llvm-svn: 92891
* Remember if the AsmStmt came from Microsoft-style inline assembly code.Mike Stump2010-01-041-1/+1
| | | | llvm-svn: 92526
* Fix 80-col violation.Zhongxing Xu2009-12-281-1/+1
| | | | llvm-svn: 92204
* Make sure to give an error for template argument lists followed by junk.Eli Friedman2009-12-271-2/+4
| | | | llvm-svn: 92177
* Enter the scope of an initializer for direct-initialization as well asDouglas Gregor2009-12-221-0/+16
| | | | | | for copy-initialization. llvm-svn: 91909
* fix PR5500: clang fails to parse inline asm with :: in C++ mode Chris Lattner2009-12-201-7/+22
| | | | llvm-svn: 91802
* refactor asm stmt parsing to avoid nesting as much, andChris Lattner2009-12-201-39/+38
| | | | | | pull ':' eating out of ParseAsmOperandsOpt. llvm-svn: 91801
* Don't inject the class name until that magical lbrace.John McCall2009-12-201-0/+2
| | | | | | | | | | | | | | | | Because of the rules of base-class lookup* and the restrictions on typedefs, it was actually impossible for this to cause any problems more serious than the spurious acceptance of template <class T> class A : B<A> { ... }; instead of template <class T> class A : B<A<T> > { ... }; but I'm sure we can all agree that that is a very important restriction which is well worth making another Parser->Sema call for. (*) n.b. clang++ does not implement these rules correctly; we are not ignoring non-type names llvm-svn: 91792
* Parse base specifiers within the scope of the class. This is possibly notJohn McCall2009-12-191-12/+18
| | | | | | quite right; I'll come back to it later. It does fix PR 5741. llvm-svn: 91789
* Refactor to remove more dependencies on PreDeclaratorDC. I seem to have madeJohn McCall2009-12-191-2/+8
| | | | | | | the redeclaration problems in the [temp.explicit]p3 testcase worse, but I can live with that; they'll need to be fixed more holistically anyhow. llvm-svn: 91771
* Just push a new scope when parsing an out-of-line variable definition.John McCall2009-12-191-2/+6
| | | | | | | Magically fixes all the terrible lookup problems associated with not pushing a new scope. Resolves an ancient xfail and an LLVM misparse. llvm-svn: 91769
* eliminate a call to NextToken() when parsing ::fooChris Lattner2009-12-191-5/+6
| | | | llvm-svn: 91738
* Teach TryAnnotateTypeOrScopeToken to deal with already-annotatedJohn McCall2009-12-192-8/+19
| | | | | | | scope specifiers. Fix a tentative parsing bug that came up in LLVM. Incidentally fixes some random FIXMEs in an existing testcase. llvm-svn: 91734
OpenPOWER on IntegriCloud