summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseDeclCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Switch parsing of using declarations over to ParseUnqualifiedId.Douglas Gregor2009-11-041-34/+15
| | | | llvm-svn: 86027
* Change our basic strategy for avoiding deprecation warnings when the decl useJohn McCall2009-11-041-2/+4
| | | | | | | | | | | | 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
* Introduce a new class, UnqualifiedId, that provides a parsedDouglas Gregor2009-11-031-0/+1
| | | | | | | | | | | | | | | | representation of a C++ unqualified-id, along with a single parsing function (Parser::ParseUnqualifiedId) that will parse all of the various forms of unqualified-id in C++. Replace the representation of the declarator name in Declarator with the new UnqualifiedId class, simplifying declarator-id parsing considerably and providing more source-location information to Sema. In the future, I hope to migrate all of the other unqualified-id-parsing code over to this single representation, then begin to merge actions that are currently only different because we didn't have a unqualified notion of the name in the parser. llvm-svn: 85851
* Improved fix for PR3844, which recovers better for class templateDouglas Gregor2009-10-301-5/+19
| | | | | | partial specializations and explicit instantiations of non-templates. llvm-svn: 85620
* Improve diagnostics when parsing something likeDouglas Gregor2009-10-301-1/+38
| | | | | | | | template<> struct foo<int> { ... }; where "foo" does not refer to a template. Fixes PR3844. llvm-svn: 85616
* Simplify the handling of non-dependent friend class templateDouglas Gregor2009-09-261-1/+1
| | | | | | | | | | | | specializations such as: friend class std::vector<int>; by using the same code path as explicit specializations, customized to reference an existing ClassTemplateSpecializationDecl (or build a new "undeclared" one). llvm-svn: 82875
* Rework the Parse-Sema interaction for friends to better support friendDouglas Gregor2009-09-261-9/+17
| | | | | | | | | class templates. We now treat friend class templates much more like normal class templates, except that they still get special name lookup rules. Fixes PR5057 and eliminates a bunch of spurious diagnostics in <iostream>. llvm-svn: 82848
* Introduce four new code-completion hooks for C++:Douglas Gregor2009-09-181-0/+20
| | | | | | | | | | - after "using", show anything that can be a nested-name-specifier. - after "using namespace", show any visible namespaces or namespace aliases - after "namespace", show any namespace definitions in the current scope - after "namespace identifier = ", show any visible namespaces or namespace aliases llvm-svn: 82251
* Implement code completion for tags, e.g., code completion after "enum"Douglas Gregor2009-09-181-0/+6
| | | | | | | | | | | | | will provide the names of various enumerations currently visible. Introduced filtering of code-completion results when we build the result set, so that we can identify just the kinds of declarations we want. This implementation is incomplete for C++, since we don't consider that the token after the tag keyword could start a nested-name-specifier. llvm-svn: 82222
* Improved representation and support for friend class templates. Angst about ↵John McCall2009-09-161-6/+5
| | | | | | same. llvm-svn: 82088
* 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
OpenPOWER on IntegriCloud