summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseDeclCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Skeletal support for friend class templates.John McCall2009-09-141-5/+2
| | | | llvm-svn: 81801
* Alter Action's friend interface to prepare for templated friend declarations andJohn McCall2009-09-111-7/+9
| | | | | | to stop making promises we can't currently keep. llvm-svn: 81571
* Just ignore friend templates for now so we won't crash.Anders Carlsson2009-09-111-3/+6
| | | | llvm-svn: 81536
* Support elaborated dependent types and diagnose tag mismatches.John McCall2009-09-111-22/+24
| | | | llvm-svn: 81504
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-123/+122
| | | | llvm-svn: 81346
* Support templateids in friend declarations. Fixes bug 4859.John McCall2009-09-081-11/+12
| | | | llvm-svn: 81233
* Parse extern templates, pass that information all the way to Sema,Douglas Gregor2009-09-041-0/+2
| | | | | | then drop it on the floor. llvm-svn: 80989
* Introduce an egregious hack to fix PR4828.Douglas Gregor2009-09-041-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | The problem this change addresses is that we treat __is_pod and __is_empty as keywords in C++, because they are built-in type traits in GCC >= 4.3. However, GNU libstdc++ 4.2 (and possibly earlier versions) define implementation-detail struct templates named __is_pod and __is_empty. This commit solves the problem by recognizing struct __is_pod and struct __is_empty as special token sequences. When one of these token sequences is encountered, the keyword (__is_pod or __is_empty) is implicitly downgraded to an identifier so that parsing can continue. This is an egregious hack, but it has the virtue of "just working" whether someone is using libstdc++ 4.2 or not, without the need for special flags. llvm-svn: 80988
* Correctly handle elaborated template ids. Still not handled properly for ↵John McCall2009-09-041-1/+26
| | | | | | friends. llvm-svn: 80977
* Rewrite of our handling of name lookup in C++ member access expressions, e.g.,Douglas Gregor2009-09-021-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Set the access specifier for using decls.Anders Carlsson2009-08-291-3/+4
| | | | llvm-svn: 80435
* More work on using declarations.Anders Carlsson2009-08-281-1/+3
| | | | llvm-svn: 80333
* When we know that we are parsing a class-name, implicitly construct aDouglas Gregor2009-08-261-1/+2
| | | | | | | | | | | | | | TypenameType if getTypeName is looking at a member of an unknown specialization. This allows us to properly parse class templates that derived from type that could only otherwise be described by a typename type, e.g., template<class T> struct X {}; template<typename T> struct Y : public X<T>::X { }; Fixes PR4381. llvm-svn: 80123
* Improve support for out-of-line definitions of nested templates andDouglas Gregor2009-08-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement delayed parsing for member function templates. Fixes PR4608.Douglas Gregor2009-08-221-0/+1
| | | | llvm-svn: 79709
* Initial support for parsing and representation of member function templates.Douglas Gregor2009-08-201-6/+20
| | | | llvm-svn: 79570
* Argument-dependent lookup for friend declarations. Add a new decl type,John McCall2009-08-111-2/+3
| | | | | | | | | | | | FriendFunctionDecl, and create instances as appropriate. The design of FriendFunctionDecl is still somewhat up in the air; you can befriend arbitrary types of functions --- methods, constructors, etc. --- and it's not clear that this representation captures that very well. We'll have a better picture when we start consuming this data in access control. llvm-svn: 78653
* First pass at friend semantics.John McCall2009-08-061-28/+24
| | | | llvm-svn: 78274
* Refactor methods on DeclSpec to take a diagnostic& parameter, and reflect thisJohn McCall2009-08-031-5/+7
| | | | | | | | 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
* Rename Action::TagKind to Action::TagUseKind, which removes both a misnomerJohn McCall2009-07-311-14/+14
| | | | | | and a name collision. llvm-svn: 77658
* Implement support for out-of-line definitions of the class members of classDouglas Gregor2009-07-221-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | templates, e.g., template<typename T> struct Outer { struct Inner; }; template<typename T> struct Outer<T>::Inner { // ... }; Implementing this feature required some extensions to ActOnTag, which now takes a set of template parameter lists, and is the precursor to removing the ActOnClassTemplate function from the parser Action interface. The reason for this approach is simple: the parser cannot tell the difference between a class template definition and the definition of a member of a class template; both have template parameter lists, and semantic analysis determines what that template parameter list means. There is still some cleanup to do with ActOnTag and ActOnClassTemplate. This commit provides the basic functionality we need, however. llvm-svn: 76820
* Fix the parsing of default arguments for inline member function Eli Friedman2009-07-221-29/+34
| | | | | | | | definitions. I'm not very familiar with this code, so please review. llvm-svn: 76796
* Issue a more descriptive diagnostics when mis-declaringFariborz Jahanian2009-07-201-2/+4
| | | | | | a destructor. llvm-svn: 76436
* Pass the right brace SourceLocation from the Parser to the TagDecls.Argyrios Kyrtzidis2009-07-141-1/+1
| | | | llvm-svn: 75591
* Patch to implement template types in ctor-initializer list.Fariborz Jahanian2009-07-011-5/+16
| | | | | | Also has fix for bugzilla-4469. llvm-svn: 74631
* Patch to support optional nested-name-specifier in in ctor-initializerFariborz Jahanian2009-06-301-3/+5
| | | | | | list. llvm-svn: 74571
* Make it possible for using decls to point to operators. Fixes PR4441.Anders Carlsson2009-06-271-8/+24
| | | | llvm-svn: 74362
* Fix PR4448.Anders Carlsson2009-06-261-2/+0
| | | | llvm-svn: 74257
* Parse the C++0x decltype specifier.Anders Carlsson2009-06-241-0/+47
| | | | llvm-svn: 74086
* Parsing and AST support for using declarations, from John Thompson!Douglas Gregor2009-06-201-6/+69
| | | | llvm-svn: 73812
* Keep track of when declarations are "used" according to C andDouglas Gregor2009-06-191-1/+1
| | | | | | | | | | | | C++. This logic is required to trigger implicit instantiation of function templates and member functions of class templates, which will be implemented separately. This commit includes support for -Wunused-parameter, printing warnings for named parameters that are not used within a function/Objective-C method/block. Fixes <rdar://problem/6505209>. llvm-svn: 73797
* Diagnose the use of attributes on namespace aliases, from Anis AhmadDouglas Gregor2009-06-171-3/+11
| | | | llvm-svn: 73626
* improve localizability by not passing english phrases into Chris Lattner2009-06-141-4/+5
| | | | | | diagnostics in some cases. llvm-svn: 73314
* Add more parser support for Microsoft extensions.Eli Friedman2009-06-081-3/+2
| | | | llvm-svn: 73101
* Add real parsing for __declspec. It doesn't make much of a difference Eli Friedman2009-06-081-1/+2
| | | | | | at the moment because we ignore the result. llvm-svn: 73056
* Reject incomplete types in exception specs.Sebastian Redl2009-05-291-3/+9
| | | | llvm-svn: 72580
* If a declarator group declares a type, make sure to add that declaration Eli Friedman2009-05-291-1/+1
| | | | | | to the DeclGroup. llvm-svn: 72559
* 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
OpenPOWER on IntegriCloud