summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseDeclCXX.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Namespaces can only be defined at global or namespace scope. Fixes PR6596.Douglas Gregor2010-05-141-0/+8
| | | | llvm-svn: 103767
* Replace a char*/size pair with stringref.Benjamin Kramer2010-05-031-1/+1
| | | | llvm-svn: 102902
* Parse friend template ids as types instead of ending up inJohn McCall2010-04-141-4/+8
| | | | | | | ActOnClassTemplateSpecialization and being very confused. Fixes PR6514 (for non-templated-scope friends). llvm-svn: 101198
* Make CXXScopeSpec invalid when incomplete, and propagate that into anyJeffrey Yasskin2010-04-081-1/+1
| | | | | | | Declarator that depends on it. This fixes several redundant errors and bad recoveries. llvm-svn: 100779
* Reinstate my CodeModificationHint -> FixItHint renaming patch, withoutDouglas Gregor2010-03-311-3/+3
| | | | | | the C-only "optimization". llvm-svn: 100022
* Revert r100008, which inexplicably breaks the clang-i686-darwin10 builderDouglas Gregor2010-03-311-3/+3
| | | | llvm-svn: 100018
* Rename CodeModificationHint to FixItHint, since we've been using theDouglas Gregor2010-03-311-3/+3
| | | | | | | term "fix-it" everywhere and even *I* get tired of long names sometimes. No functionality change. llvm-svn: 100008
* Support __attribute__((packed)) (along with other attributes) at theDouglas Gregor2010-03-291-2/+3
| | | | | | end of a struct/class/union in C++, from Justin Bogner! llvm-svn: 99811
* Clean up after ourselves when there's an error parsing the base clause.John McCall2010-03-171-2/+5
| | | | | | Fixes the crash-on-invalid in PR6629. llvm-svn: 98698
* Audit all Preprocessor::getSpelling() callers, improving failureDouglas Gregor2010-03-161-1/+4
| | | | | | recovery for those that need it. llvm-svn: 98689
* Use SmallString instead of SmallVectorKovarththanan Rajaratnam2010-03-131-47/+47
| | | | llvm-svn: 98436
* Fix an amusing typo that completely the re-introduction of parametersDouglas Gregor2010-03-021-1/+1
| | | | | | | | | | | for the purposes of parsing default arguments. In effect, we would re-introduce the parameter with a default argument N times (where N is the number of parameters preceding the parameter with a default argument). This showed up when a defaulted parameter of a member function of a local class shadowed a parameter of the enclosing function. Fixes PR6383. llvm-svn: 97534
* Add commentDouglas Gregor2010-03-021-1/+2
| | | | llvm-svn: 97528
* 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
OpenPOWER on IntegriCloud