summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseDeclCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* When we're parsing template names as part of base-specifiers, we areDouglas Gregor2010-03-011-1/+1
| | | | | | | | *not* entering the context of the nested-name-specifier. This was causing us to look into an uninstantiated template that we shouldn't look into. Fixes PR6376. llvm-svn: 97524
* Implement PR6423 by using one token of lookahead to disambiguate Chris Lattner2010-02-281-9/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | an *almost* always incorrect case. This only does the lookahead in the insanely unlikely case, so it shouldn't impact performance. On this testcase: struct foo { } typedef int x; Before: t.c:3:9: error: cannot combine with previous 'struct' declaration specifier typedef int x; ^ After: t.c:2:2: error: expected ';' after struct } ^ ; llvm-svn: 97403
* Add an overload of Preprocessor::getSpelling which takes a SmallVector andBenjamin Kramer2010-02-271-4/+2
| | | | | | returns a StringRef. Use it to simplify some repetitive code. llvm-svn: 97322
* Fix an assertion-on-error during tentative constructor parsing byJohn McCall2010-02-261-2/+3
| | | | | | | | | | propagating error conditions out of the various annotate-me-a-snowflake routines. Generally (but not universally) removes redundant diagnostics as well as, you know, not crashing on bad code. On the other hand, I have just signed myself up to fix fiddly parser errors for the next week. Again. llvm-svn: 97221
* Improve parsing and instantiation of destructor names, so that we canDouglas Gregor2010-02-161-4/+2
| | | | | | | | | | | | | | | | | | | | | | | now cope with the destruction of types named as dependent templates, e.g., y->template Y<T>::~Y() Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't follow the letter of the standard here because that would fail to parse template<typename T, typename U> X0<T, U>::~X0() { } properly. The problem is captured in core issue 339, which gives some (but not enough!) guidance. I expect to revisit this code when the resolution of 339 is clear, and/or we start capturing better source information for DeclarationNames. Fixes PR6152. llvm-svn: 96367
* Clean up ownership of 'AttributeList' objects in Parser. ApparentlyTed Kremenek2010-02-111-9/+9
| | | | | | | | | | | | | | | | | | | | | 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
* Fix assertion failure when parsing linkage specifications (PR5921),Douglas Gregor2010-02-071-0/+2
| | | | | | from Keir Mierle! llvm-svn: 95516
* Add attributes to namespace decls.Anders Carlsson2010-02-071-2/+2
| | | | llvm-svn: 95510
* In some contexts, type declarations cannot occur. Pass this information down ↵Sebastian Redl2010-02-031-3/+11
| | | | | | 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
* 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
* 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
* Move the type specifier location for elaborated-type-specifiers fromDouglas Gregor2010-01-251-1/+5
| | | | | | | 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
* Implement elementary access control.John McCall2010-01-231-1/+1
| | | | llvm-svn: 94268
* 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
* 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
* 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
* Remember the type name's scope specifier in the DeclSpec.John McCall2009-12-121-1/+1
| | | | llvm-svn: 91215
* Implement access declarations. Most of the work here is parsing them, whichJohn McCall2009-12-111-1/+41
| | | | | | | | | | | | is difficult because they're so terribly, terribly ambiguous. We implement access declarations in terms of using declarations, which is quite reasonable. However, we should really persist the access/using distinction in the AST and use the appropriate name in diagnostics. This isn't a priority, so I'll just file a PR and hope someone else does it. :) llvm-svn: 91095
* fix incorrect parsing of bitfields pointed out by Doug. I choseChris Lattner2009-12-101-2/+7
| | | | | | | to use ColonProtectionRAIIObject in the C codepath even though it won't matter for consistency. llvm-svn: 91037
* refactor the 'ColonIsSacred' argument to ParseOptionalCXXScopeSpecifierChris Lattner2009-12-101-4/+8
| | | | | | | 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-2/+3
| | | | | | (fixes radar 7457109). llvm-svn: 90986
* remove some defaulted params for consistency.Chris Lattner2009-12-071-3/+3
| | | | llvm-svn: 90731
* reapply my patch for PR4451, which improves diagnostics for :: vs : confusion.Chris Lattner2009-12-071-4/+4
| | | | | | This time with a fix to bail out when in a dependent context. llvm-svn: 90730
* revert my previous patch, it is breaking something and I don't have timeChris Lattner2009-12-061-4/+4
| | | | | | to fix it ATM. llvm-svn: 90717
* implement PR4451, improving error recovery for a mistaken : where a :: wasChris Lattner2009-12-061-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | intended. On the first testcase in the bug, we now produce: cxx-decl.cpp:12:2: error: unexpected ':' in nested name specifier y:a a2; ^ :: instead of: t.cc:8:1: error: C++ requires a type specifier for all declarations x:a a2; ^ t.cc:8:2: error: invalid token after top level declarator x:a a2; ^ ; t.cc:9:11: error: use of undeclared identifier 'a2' x::a a3 = a2; ^ llvm-svn: 90713
* remove some extraneous syntax: sourceloc implicitly converts to sourcerange.Chris Lattner2009-12-061-2/+2
| | | | llvm-svn: 90710
* Fix attribute between function decl ')' and '{' or '=0'John Thompson2009-11-251-0/+7
| | | | llvm-svn: 89894
* Parse C++ member check attributes - base_check, hiding, and override.Alexis Hunt2009-11-251-2/+5
| | | | | | The attributes are currently ignored. llvm-svn: 89837
* Have the parser tell sema whether a member declaration is a function ↵Sebastian Redl2009-11-241-0/+1
| | | | | | definition. This allows sema to not emit spurious diagnostics in some invalid code. llvm-svn: 89816
* Added rudimentary C++0x attribute support.Alexis Hunt2009-11-211-26/+233
| | | | | | | | | | | | | | 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
* Incremental progress on using declarations. Split UnresolvedUsingDecl intoJohn McCall2009-11-181-1/+3
| | | | | | | | | | two classes, one for typenames and one for values; this seems to have some support from Doug if not necessarily from the extremely-vague-on-this-point standard. Track the location of the 'typename' keyword in a using-typename decl. Make a new lookup result for unresolved values and deal with it in most places. llvm-svn: 89184
* Improve parsing of template arguments to lay the foundation forDouglas Gregor2009-11-101-8/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* add some fixit hints.Chris Lattner2009-11-061-1/+2
| | | | llvm-svn: 86240
* 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
OpenPOWER on IntegriCloud