summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Diagnose the declaration of enum templates. Also, be a bit moreDouglas Gregor2010-03-021-3/+13
| | | | | | careful about value-dependent enumerators. Fixes PR5786. llvm-svn: 97570
* Robustify instantiation of templates when there are errors in theDouglas Gregor2010-03-011-4/+4
| | | | | | | | | template definition. Do this both by being more tolerant of errors in our asserts and by not dropping a variable declaration completely when its initializer is ill-formed. Fixes the crash-on-invalid in PR6375, but not the original issue. llvm-svn: 97463
* Don't infinite-loop if TryAnnotateCXXScopeToken fails to annotate but doesn'tJohn McCall2010-03-011-0/+2
| | | | | | | | | signal an error. This can happen even when the current token is '::' if this is a ::new or ::delete expression. This was an oversight in my recent parser refactor; fixes PR 5825. llvm-svn: 97462
* pull some altivec stuff out of line.Chris Lattner2010-02-281-0/+66
| | | | llvm-svn: 97405
* Implement PR6423 by using one token of lookahead to disambiguate Chris Lattner2010-02-281-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix an assertion-on-error during tentative constructor parsing byJohn McCall2010-02-261-36/+60
| | | | | | | | | | 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
* Only parse C++0x attribute specifiers in declarators when in C++0xDouglas Gregor2010-02-191-1/+1
| | | | | | | mode. This allows us to detect invalid VLAs in Objective-C++ mode. This should be the last of <rdar://problem/7660386>. llvm-svn: 96679
* Improve the diagnostic given when referring to a tag type without a tag (in C)John McCall2010-02-141-1/+1
| | | | | | | | | or that's been hidden by a non-type (in C++). The ideal C++ diagnostic here would note the hiding declaration, but this is a good start. llvm-svn: 96141
* Clean up ownership of 'AttributeList' objects in Parser. ApparentlyTed Kremenek2010-02-111-14/+15
| | | | | | | | | | | | | | | | | | | | | 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
* First stage of adding AltiVec supportJohn Thompson2010-02-051-3/+32
| | | | llvm-svn: 95335
* In some contexts, type declarations cannot occur. Pass this information down ↵Sebastian Redl2010-02-031-4/+6
| | | | | | to ParseClassSpecifier, to make its decision easier. Fixes PR6200. llvm-svn: 95255
* improve diagnostics on missing ; in a struct. Before:Chris Lattner2010-02-021-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | t.c:4:3: error: expected ';' at end of declaration list int y; ^ t.c:4:8: warning: extra ';' inside a struct or union int y; ^ t.c:6:1: warning: expected ';' at end of declaration list }; ^ After: t.c:3:8: error: expected ';' at end of declaration list int x // expected-error {{expected ';' at end of declaration list}} ^ ; t.c:5:8: warning: expected ';' at end of declaration list int z ^ ; llvm-svn: 95038
* Move the type specifier location for elaborated-type-specifiers fromDouglas Gregor2010-01-251-2/+4
| | | | | | | 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
* Whenever completing ordinary names for an Objective-C source, alsoDouglas Gregor2010-01-131-1/+3
| | | | | | | | | | | provide completions for @ keywords. Previously, we only provided @-completions after an @ was actually typed, which is useful but probably not the common case. Also, make sure a few Objective-C 2.0 completions only show up when Objective-C 2.0 support is enabled (the default). llvm-svn: 93354
* Add type source information for both kinds of typeof types.John McCall2010-01-131-0/+4
| | | | | | Patch by Enea Zaffanella. llvm-svn: 93344
* Reimplement constructor declarator parsing to cope with template-idsDouglas Gregor2010-01-131-18/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that name constructors, the endless joys of out-of-line constructor definitions, and various other corner cases that the previous hack never imagined. Fixes PR5688 and tightens up semantic analysis for constructor names. Additionally, fixed a problem where we wouldn't properly enter the declarator scope of a parenthesized declarator. We were entering the scope, then leaving it when we saw the ")"; now, we re-enter the declarator scope before parsing the parameter list. Note that we are forced to perform some tentative parsing within a class (call it C) to tell the difference between C(int); // constructor and C (f)(int); // member function which is rather unfortunate. And, although it isn't necessary for correctness, we use the same tentative-parsing mechanism for out-of-line constructors to improve diagnostics in icky cases like: C::C C::f(int); // error: C::C refers to the constructor name, but // we complain nicely and recover by treating it as // a type. llvm-svn: 93322
* Improve code completion by introducing patterns for the various C andDouglas Gregor2010-01-101-1/+8
| | | | | | | | | | | | | | | | | | | | | | C++ grammatical constructs that show up in top-level (namespace-level) declarations, member declarations, template declarations, statements, expressions, conditions, etc. For example, we now provide a pattern for static_cast<type>(expr) when we can have an expression, or using namespace identifier; when we can have a using directive. Also, improves the results of code completion at the beginning of a top-level declaration. Previously, we would see value names (function names, global variables, etc.); now we see types, namespace names, etc., but no values. llvm-svn: 93134
* Fix 80-col violation.Zhongxing Xu2009-12-281-1/+1
| | | | llvm-svn: 92204
* Enter the scope of an initializer for direct-initialization as well asDouglas Gregor2009-12-221-0/+16
| | | | | | for copy-initialization. llvm-svn: 91909
* Just push a new scope when parsing an out-of-line variable definition.John McCall2009-12-191-2/+6
| | | | | | | Magically fixes all the terrible lookup problems associated with not pushing a new scope. Resolves an ancient xfail and an LLVM misparse. llvm-svn: 91769
* Remember the type name's scope specifier in the DeclSpec.John McCall2009-12-121-8/+9
| | | | llvm-svn: 91215
* Don't enter a new scope for a namespace-qualified declarator unless we'reJohn McCall2009-12-111-3/+4
| | | | | | | in a file context. In well-formed code, only happens with friend functions. Fixes PR 5760. llvm-svn: 91146
* fix incorrect parsing of bitfields pointed out by Doug. I choseChris Lattner2009-12-101-2/+4
| | | | | | | to use ColonProtectionRAIIObject in the C codepath even though it won't matter for consistency. llvm-svn: 91037
* rename ExtensionRAIIObject.h -> RAIIObjectsForParser.hChris Lattner2009-12-101-1/+1
| | | | llvm-svn: 91008
* remove some extraneous syntax: sourceloc implicitly converts to sourcerange.Chris Lattner2009-12-061-2/+2
| | | | llvm-svn: 90710
* Added rudimentary C++0x attribute support.Alexis Hunt2009-11-211-35/+91
| | | | | | | | | | | | | | 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
* Improve parsing of template arguments to lay the foundation forDouglas Gregor2009-11-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* Parse C++0x constexpr. Test case follows when this does something useful.Sebastian Redl2009-11-051-0/+6
| | | | llvm-svn: 86135
* Change our basic strategy for avoiding deprecation warnings when the decl useJohn McCall2009-11-041-4/+11
| | | | | | | | | | | | 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
* CFieldCallback doesn't need to create an ExtensionRAIIObject: it's actuallyJohn McCall2009-11-031-14/+3
| | | | | | | automatically shadowed by the ExtensionRAIIObject created by ParseStructDeclaration. llvm-svn: 85941
* Replace the code that parses member access expressions after "." orDouglas Gregor2009-11-031-1/+2
| | | | | | | | | | | | "->" with a use of ParseUnqualifiedId. Collapse ActOnMemberReferenceExpr, ActOnDestructorReferenceExpr (both of them), ActOnOverloadedOperatorReferenceExpr, ActOnConversionOperatorReferenceExpr, and ActOnMemberTemplateIdReferenceExpr into a single, new action ActOnMemberAccessExpr that does the same thing more cleanly (and can keep more source-location information). llvm-svn: 85930
* Reorganize the parsing of decl groups / function definitions so thatJohn McCall2009-11-031-76/+90
| | | | | | | declarators are parsed primarily within a single function (at least for these cases). Remove some excess diagnostics arising during parse failures. llvm-svn: 85924
* Switch ParseStructDeclaration to a callback-based API. This will makeJohn McCall2009-11-031-34/+45
| | | | | | it easier to track within Sema whether the parser is parsing a declaration. llvm-svn: 85855
* Introduce a new class, UnqualifiedId, that provides a parsedDouglas Gregor2009-11-031-82/+31
| | | | | | | | | | | | | | | | 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
* Improve diagnostics when the parser encounters a declarator with anDouglas Gregor2009-10-131-6/+29
| | | | | | | | | | | | | | | | | | | | | | | unknown type name, e.g., foo::bar x; when "bar" does not refer to a type in "foo". With this change, the parser now calls into the action to perform diagnostics and can try to recover by substituting in an appropriate type. For example, this allows us to easily diagnose some missing "typename" specifiers, which we now do: test/SemaCXX/unknown-type-name.cpp:29:1: error: missing 'typename' prior to dependent type name 'A<T>::type' A<T>::type A<T>::f() { return type(); } ^~~~~~~~~~ typename Fixes PR3990. llvm-svn: 84053
* Keep protocol source locations when parsing protocol references.Argyrios Kyrtzidis2009-09-291-12/+24
| | | | llvm-svn: 83091
* Parse a C++ scope specifier followed by a "typename" annotation token as a ↵Douglas Gregor2009-09-281-0/+13
| | | | | | type name within the declaration specifiers. Fixes PR5061. llvm-svn: 82974
* Declarators can now properly represent template-ids, e.g., forDouglas Gregor2009-09-251-11/+3
| | | | | | | | | | | template void f<int>(int); ~~~~~~ Previously, we silently dropped the template arguments. With this change, we now use the template arguments (when available) as the explicitly-specified template arguments used to aid template argument deduction for explicit template instantiations. llvm-svn: 82806
* WIP implementation of explicit instantiation of function templates,Douglas Gregor2009-09-251-4/+27
| | | | | | | | member functions of class template specializations, and static data members. The mechanics are (mostly) present, but the semantic analysis is very weak. llvm-svn: 82789
* In C++, a variadic function does not need an ellipsis prior to the comma. ↵Douglas Gregor2009-09-221-1/+16
| | | | | | Parse it in both C and C++, but diagnose it as an error in C with a fix-it hint to add the comma. llvm-svn: 82576
* Code completion for ordinary names when we're starting a declaration, ↵Douglas Gregor2009-09-211-0/+5
| | | | | | expression, or statement llvm-svn: 82481
* Implement code completion for tags, e.g., code completion after "enum"Douglas Gregor2009-09-181-1/+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
* Support elaborated dependent types and diagnose tag mismatches.John McCall2009-09-111-1/+3
| | | | llvm-svn: 81504
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-178/+178
| | | | llvm-svn: 81346
* Rewrite of our handling of name lookup in C++ member access expressions, e.g.,Douglas Gregor2009-09-021-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* When we know that we are parsing a class-name, implicitly construct aDouglas Gregor2009-08-261-1/+1
| | | | | | | | | | | | | | 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
* Fix bug in __extension__ handling for declarations, from AbramoDouglas Gregor2009-08-261-3/+14
| | | | | | Bagnara with a fix from Enea Zaffanella! llvm-svn: 80094
* Improve support for out-of-line definitions of nested templates andDouglas Gregor2009-08-251-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Introduce support for constructor templates, which can now be declaredDouglas Gregor2009-08-211-1/+4
| | | | | | | | and will participate in overload resolution. Unify the instantiation of CXXMethodDecls and CXXConstructorDecls, which had already gotten out-of-sync. llvm-svn: 79658
* Keep track of the right paren ')' source location in a function declarator.Argyrios Kyrtzidis2009-08-191-11/+14
| | | | llvm-svn: 79489
OpenPOWER on IntegriCloud