summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseDeclCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* When we parse a tag specifier, keep track of whether that tagDouglas Gregor2009-05-281-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specifier resulted in the creation of a new TagDecl node, which happens either when the tag specifier was a definition or when the tag specifier was the first declaration of that tag type. This information has several uses, the first of which is implemented in this commit: 1) In C++, one is not allowed to define tag types within a type specifier (e.g., static_cast<struct S { int x; } *>(0) is ill-formed) or within the result or parameter types of a function. We now diagnose this. 2) We can extend DeclGroups to contain information about any tags that are declared/defined within the declaration specifiers of a variable, e.g., struct Point { int x, y, z; } p; This will help improve AST printing and template instantiation, among other things. 3) For C99, we can keep track of whether a tag type is defined within the type of a parameter, to properly cope with cases like, e.g., int bar(struct T2 { int x; } y) { struct T2 z; } We can also do similar things wherever there is a type specifier, e.g., to keep track of where the definition of S occurs in this legal C99 code: (struct S { int x, y; } *)0 llvm-svn: 72555
* Reimplement much of the way that we track nested classes in theDouglas Gregor2009-05-271-22/+69
| | | | | | | | | | | | | 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
* Improve name lookup for and template instantiation of declarationDouglas Gregor2009-05-271-1/+3
| | | | | | | | | | | | | | | | | | | | | | | references. There are several smallish fixes here: - Make sure we look through template parameter scope when determining whether we're parsing a nested class (or nested class *template*). This makes sure that we delay parsing the bodies of inline member functions until after we're out of the outermost class (template) scope. - Since the bodies of member functions are always parsed "out-of-line", even when they were declared in-line, teach unqualified name lookup to look into the (semantic) parents. - Use the new InstantiateDeclRef to handle the instantiation of a reference to a declaration (in DeclRefExpr), which drastically simplifies template instantiation for DeclRefExprs. - When we're instantiating a ParmVarDecl, it must be in the current instantiation scope, so only look there. Also, remove the #if 0's and FIXME's from the dynarray example, which now compiles and executes thanks to Anders and Eli. llvm-svn: 72481
* Merge the ASTVector and ASTOwningVector templates, since they offeredDouglas Gregor2009-05-211-1/+0
| | | | | | | | 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. llvm-svn: 72214
* Use v.data() instead of &v[0] when SmallVector v might be empty.Jay Foad2009-05-211-4/+5
| | | | llvm-svn: 72210
* Implement explicit instantiations of member classes of class templates, e.g.,Douglas Gregor2009-05-141-6/+26
| | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 71756
* Implement parsing for explicit instantiations of class templates, e.g.,Douglas Gregor2009-05-121-8/+66
| | | | | | | | | 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
* Fix test case by always setting the type spec type, even for friend decls.Anders Carlsson2009-05-111-5/+4
| | | | llvm-svn: 71486
* Add an ActOnFriendDecl and call it for friend class decls.Anders Carlsson2009-05-111-3/+11
| | | | llvm-svn: 71482
* For friend class decls, always use TK_Reference so we'll try to look up ↵Anders Carlsson2009-05-111-1/+1
| | | | | | existing class decls first. llvm-svn: 71481
* Have the parser communicate the exception specification to the action.Sebastian Redl2009-04-291-3/+8
| | | | llvm-svn: 70389
* Implement function-try-blocks. However, there's a very subtle bug that I ↵Sebastian Redl2009-04-261-1/+3
| | | | | | can't track down. llvm-svn: 70155
* Diagnose invalid uses of tagged types with a missing tag. For example, in:Chris Lattner2009-04-121-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | struct xyz { int y; }; enum abc { ZZZ }; static xyz b; abc c; we used to produce: t2.c:4:8: error: unknown type name 'xyz' static xyz b; ^ t2.c:5:1: error: unknown type name 'abc' abc c; ^ we now produce: t2.c:4:8: error: use of tagged type 'xyz' without 'struct' tag static xyz b; ^ struct t2.c:5:1: error: use of tagged type 'abc' without 'enum' tag abc c; ^ enum GCC produces the normal: t2.c:4: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘b’ t2.c:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’ rdar://6783347 llvm-svn: 68914
* Parse deleted member functions. Parsing member declarations goes through a ↵Sebastian Redl2009-04-121-5/+17
| | | | | | | | | different code path that I forgot previously. Implement the rvalue reference overload dance for returning local objects. Returning a local object first tries to find a move constructor now. The error message when no move constructor is defined (or is not applicable) and the copy constructor is deleted is quite ugly, though. llvm-svn: 68902
* fix a FIXME, providing accurate source range info for DeclStmt's. The endChris Lattner2009-04-021-13/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make parsing a semantic analysis a little more robust following SemaDouglas Gregor2009-04-011-11/+13
| | | | | | | | | | | | | | | | failures that involve malformed types, e.g., "typename X::foo" where "foo" isn't a type, or "std::vector<void>" that doens't instantiate properly. Similarly, be a bit smarter in our handling of ambiguities that occur in Sema::getTypeName, to eliminate duplicate error messages about ambiguous name lookup. This eliminates two XFAILs in test/SemaCXX, one of which was crying out to us, trying to tell us that we were producing repeated error messages. llvm-svn: 68251
* Parsing and AST representation for dependent template names that occurDouglas Gregor2009-03-311-2/+2
| | | | | | | | | | | within nested-name-specifiers, e.g., for the "apply" in typename MetaFun::template apply<T1, T2>::type At present, we can't instantiate these nested-name-specifiers, so our testing is sketchy. llvm-svn: 68081
* Improve the representation of template names in the AST. ThisDouglas Gregor2009-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | representation handles the various ways in which one can name a template, including unqualified references ("vector"), qualified references ("std::vector"), and dependent template names ("MetaFun::template apply"). One immediate effect of this change is that the representation of nested-name-specifiers in type names for class template specializations (e.g., std::vector<int>) is more accurate. Rather than representing std::vector<int> as std::(vector<int>) we represent it as (std::vector)<int> which more closely follows the C++ grammar. Additionally, templates are no longer represented as declarations (DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new OpaquePtr type (TemplateTy) that holds the representation of a TemplateName. This will simplify the handling of dependent template-names, once we get there. llvm-svn: 68074
* Push DeclGroup much farther throughout the compiler. Now the variousChris Lattner2009-03-291-30/+36
| | | | | | | | | | | | | | | | | | | | | | | | | productions (except the already broken ObjC cases like @class X,Y;) in the parser that can produce more than one Decl return a DeclGroup instead of a Decl, etc. This allows elimination of the Decl::NextDeclarator field, and exposes various clients that should look at all decls in a group, but which were only looking at one (such as the dumper, printer, etc). These have been fixed. Still TODO: 1) there are some FIXME's in the code about potentially using DeclGroup for better location info. 2) ParseObjCAtDirectives should return a DeclGroup due to @class etc. 3) I'm not sure what is going on with StmtIterator.cpp, or if it can be radically simplified now. 4) I put a truly horrible hack in ParseTemplate.cpp. I plan to bring up #3/4 on the mailing list, but don't plan to tackle #1/2 in the short term. llvm-svn: 68002
* reduce indentation with an early exit.Chris Lattner2009-03-291-25/+23
| | | | llvm-svn: 67997
* Parse the location of the 'namespace' token to ActOnNamespaceAliasDef. No ↵Anders Carlsson2009-03-281-6/+7
| | | | | | functionality change. llvm-svn: 67961
* Introduce a new OpaquePtr<N> struct type, which is a simple POD wrapper for aChris Lattner2009-03-281-38/+36
| | | | | | | | | | | | | | | | | | | | pointer. Its purpose in life is to be a glorified void*, but which does not implicitly convert to void* or other OpaquePtr's with a different UID. Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>. Change the entire parser/sema interface to use DeclPtrTy instead of DeclTy*. This makes the C++ compiler enforce that these aren't convertible to other opaque types. We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc, but I don't plan to do that in the short term. The one outstanding known problem with this patch is that we lose the bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to bitmangle the success bit into the low bit of DeclPtrTy. I will rectify this with a subsequent patch. llvm-svn: 67952
* Add an ActOnNamespaceAliasDef action and have the parser call it.Anders Carlsson2009-03-281-1/+2
| | | | llvm-svn: 67915
* Parse namespace aliases.Anders Carlsson2009-03-281-4/+35
| | | | llvm-svn: 67908
* Handle parsing of templates in member declarations. Pass the AccessSpecifier ↵Anders Carlsson2009-03-261-2/+7
| | | | | | | | all the way down to ActOnClassTemplate. Doug, Sebastian: Plz review! :) llvm-svn: 67723
* Pass access specifiers through to member classes and member enums.Douglas Gregor2009-03-251-3/+4
| | | | llvm-svn: 67710
* In Parser::ParseClassSpecifier, don't conflate a NULL declaration withDouglas Gregor2009-03-251-10/+12
| | | | | | | | failure to perform a declaration. Instead, explicitly note semantic failures that occur during template parsing with a DeclResult. Fixes PR3872. llvm-svn: 67659
* Handle static_asserts when instantiating structs.Anders Carlsson2009-03-151-3/+2
| | | | llvm-svn: 67031
* Pass more sane arguments to ActOnStaticAssertDeclarationAnders Carlsson2009-03-131-9/+4
| | | | llvm-svn: 66983
* Add parser support for static_assert.Anders Carlsson2009-03-111-1/+54
| | | | llvm-svn: 66661
* rename PrettyStackTraceDecl -> PrettyStackTraceActionsDecl.Chris Lattner2009-03-051-6/+6
| | | | | | | | | | | | | | | | Introduce a new PrettyStackTraceDecl. Use it to add the top level LLVM IR generation stuff in Backend.cpp to stack traces. We now get crashes like: Stack dump: 0. Program arguments: clang t.c -emit-llvm 1. <eof> parser at end of file 2. t.c:1:5: LLVM IR generation of declaration 'a' Abort for IR generation crashes. llvm-svn: 66153
* Include struct context info for parser/sema crashes. ThisChris Lattner2009-03-051-0/+4
| | | | | | | | | | | | | | | | | | | | | gives us: Stack dump: 0. using-directive.cpp:26:16: in compound statement ('{}') 1. using-directive.cpp:26:16: parsing function body 'A::K1::foo' 2. using-directive.cpp:25:3: parsing struct/union/class body 'A::K1' 3. using-directive.cpp:5:1: parsing namespace 'A' 4. clang using-directive.cpp Abort for code like: namespace A { ... class K1 { void foo() { <<crash>> llvm-svn: 66124
* Include namespace contexts in the virtual stack trace, so we get stuffChris Lattner2009-03-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | like this: Stack dump: 0. using-directive.cpp:9:14: in compound statement ('{}') 1. using-directive.cpp:9:14: parsing function body 'A::B::f' 2. using-directive.cpp:7:3: parsing namespace 'A::B' 3. using-directive.cpp:5:1: parsing namespace 'A' 4. clang using-directive.cpp Abort for testcase like like: namespace A { short i; namespace B { long i; void f() { <<crash>> llvm-svn: 66123
* Implementing parsing of template-ids as class-names, so that we canDouglas Gregor2009-02-251-9/+26
| | | | | | | | derive from a class template specialization, e.g., class B : public A<int> { }; llvm-svn: 65488
* Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor2009-02-251-65/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. llvm-svn: 65467
* Implement basic parsing and semantic analysis for explicitDouglas Gregor2009-02-171-3/+71
| | | | | | | | | | | | | | | | | | specialization of class templates, e.g., template<typename T> class X; template<> class X<int> { /* blah */ }; Each specialization is a different *Decl node (naturally), and can have different members. We keep track of forward declarations and definitions as for other class/struct/union types. This is only the basic framework: we still have to deal with checking the template headers properly, improving recovery when there are failures, handling nested name specifiers, etc. llvm-svn: 64848
* diagnose uses of deprecated typenames and tags.Chris Lattner2009-02-161-2/+1
| | | | | | We now pass all the deprecation tests in the objc.dg suite. llvm-svn: 64679
* Implement Declarator::getSourceRange().Sebastian Redl2009-02-091-7/+13
| | | | llvm-svn: 64151
* Semantic checking for class template declarations andDouglas Gregor2009-02-061-10/+20
| | | | | | | | | | | | | | | redeclarations. For example, checks that a class template redeclaration has the same template parameters as previous declarations. Detangled class-template checking from ActOnTag, whose logic was getting rather convoluted because it tried to handle C, C++, and C++ template semantics in one shot. Made some inroads toward eliminating extraneous "declaration does not declare anything" errors by adding an "error" type specifier. llvm-svn: 63973
* Basic representation of C++ class templates, from Andrew Sutton.Douglas Gregor2009-02-041-6/+6
| | | | llvm-svn: 63750
* Diagnose ambiguities in getTypeName. Fixes ↵Douglas Gregor2009-02-041-1/+2
| | | | | | http://llvm.org/bugs/show_bug.cgi?id=3475 llvm-svn: 63737
* move library-specific diagnostic headers into library private dirs. ReduceChris Lattner2009-01-291-1/+1
| | | | | | redundant #includes. Patch by Anders Johnsen! llvm-svn: 63271
* Name change (isTypeName->getTypeName).Steve Naroff2009-01-281-1/+1
| | | | | | Since it doesn't return a bool, is shouldn't be prefixed with 'is'. llvm-svn: 63226
* Split the single monolithic DiagnosticKinds.def file into oneChris Lattner2009-01-271-1/+1
| | | | | | | | | .def file for each library. This means that adding a diagnostic to sema doesn't require all the other libraries to be rebuilt. Patch by Anders Johnsen! llvm-svn: 63111
* Some micro-optimizations for DISABLE_SMART_POINTERS:Douglas Gregor2009-01-261-4/+4
| | | | | | | | | | | | | | | | | - When it's safe, ActionResult uses the low bit of the pointer for the "invalid" flag rather than a separate "bool" value. This keeps GCC from generating some truly awful code, for a > 3x speedup in the result-passing microbenchmark. - When DISABLE_SMART_POINTERS is defined, store an ActionResult within ASTOwningResult rather than an ASTOwningPtr. Brings the performance benefits of the above to smart pointers with DISABLE_SMART_POINTERS defined. Sadly, these micro-benchmark performance improvements don't seem to make much of a difference on Cocoa.h right now. However, they're harmless and might help with future optimizations. llvm-svn: 63061
* When we see a reference to a struct, class, or union like "struct X"Douglas Gregor2009-01-091-3/+3
| | | | | | | | | | | | | | | | that is neither a definition nor a forward declaration and where X has not yet been declared as a tag, introduce a declaration into the appropriate scope (which is likely *not* to be the current scope). The rules for the placement of the declaration differ slightly in C and C++, so we implement both and test the various corner cases. This implementation isn't 100% correct due to some lingering issues with the function prototype scope (for a function parameter list) not being the same scope as the scope of the function definition. Testcase is FIXME'd; this probably isn't an important issue. Addresses <rdar://problem/6484805>. llvm-svn: 62014
* Unify the code for defining tags in C and C++, so that we alwaysDouglas Gregor2009-01-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | introduce a Scope for the body of a tag. This reduces the number of semantic differences between C and C++ structs and unions, and will help with other features (e.g., anonymous unions) in C. Some important points: - Fields are now in the "member" namespace (IDNS_Member), to keep them separate from tags and ordinary names in C. See the new test in Sema/member-reference.c for an example of why this matters. In C++, ordinary and member name lookup will find members in both the ordinary and member namespace, so the difference between IDNS_Member and IDNS_Ordinary is erased by Sema::LookupDecl (but only in C++!). - We always introduce a Scope and push a DeclContext when we're defining a tag, in both C and C++. Previously, we had different actions and different Scope/CurContext behavior for enums, C structs/unions, and C++ structs/unions/classes. Now, it's one pair of actions. (Yay!) There's still some fuzziness in the handling of struct/union/enum definitions within other struct/union/enum definitions in C. We'll need to do some more cleanup to eliminate some reliance on CurContext before we can solve this issue for real. What we want is for something like this: struct X { struct T { int x; } t; }; to introduce T into translation unit scope (placing it at the appropriate point in the IdentifierResolver chain, too), but it should still have struct X as its lexical declaration context. PushOnScopeChains isn't smart enough to do that yet, though, so there's a FIXME test in nested-redef.c llvm-svn: 61940
* - Various comment typo fixes in Sema.hChris Lattner2009-01-061-16/+14
| | | | | | | | | - Simplify ParseDeclCXX to use early exit on error instead of nesting. - Change ParseDeclCXX to using the 'skip on error' form of ExpectAndConsume. - If we don't see the ; in a using directive, still call the action, for hopefully better error recovery. llvm-svn: 61801
* rename MaybeParseCXXScopeSpecifier -> ParseOptionalCXXScopeSpecifier and Chris Lattner2009-01-061-3/+3
| | | | | | MaybeParseTypeSpecifier -> ParseOptionalTypeSpecifier. llvm-svn: 61796
* minor code cleanups, reduce indentation since 'if' block can't fall through.Chris Lattner2009-01-061-7/+5
| | | | llvm-svn: 61795
OpenPOWER on IntegriCloud