summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseDecl.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix: <rdar://problem/7021553> clang -fsyntax-only crashes (in ↵Ted Kremenek2009-06-301-4/+4
| | | | | | | | | ParseDeclarationSpecifiers ... from ParseObjCTypeName) Another case where we should use SmallVector::data() instead of taking the address of element 0 of a SmallVector when the SmallVector has no elements. llvm-svn: 74556
* Fix test.Anders Carlsson2009-06-261-0/+7
| | | | llvm-svn: 74358
* Implement enough of the 'auto' keyword so we can claim to support N2546.Anders Carlsson2009-06-261-1/+4
| | | | llvm-svn: 74307
* OpenCL 1.0 support: attributesNate Begeman2009-06-261-2/+25
| | | | llvm-svn: 74280
* Parse the C++0x decltype specifier.Anders Carlsson2009-06-241-0/+10
| | | | llvm-svn: 74086
* Start propagating template parameter lists to the right places toDouglas Gregor2009-06-231-2/+9
| | | | | | | handle function templates. There's no actual code for function templates yet, but at least we complain about typedef templates. llvm-svn: 74021
* Implement implicit instantiation of the member functions of a class templateDouglas Gregor2009-06-221-1/+1
| | | | | | | specialization. At present, all implicit instantiations occur at the end of the translation unit. llvm-svn: 73915
* Keep track of when declarations are "used" according to C andDouglas Gregor2009-06-191-2/+6
| | | | | | | | | | | | 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
* Implement correct name lookup inside an initializer of a C++ class static ↵Argyrios Kyrtzidis2009-06-171-0/+7
| | | | | | | | data member. Fixes "test/CXX/basic/basic.lookup/basic.lookup.unqual/p13.cpp" test case. llvm-svn: 73652
* It's an error to use a function declared in a class definition as a default ↵Anders Carlsson2009-06-121-1/+2
| | | | | | argument before the function has been declared. llvm-svn: 73234
* Add more parser support for Microsoft extensions.Eli Friedman2009-06-081-23/+48
| | | | llvm-svn: 73101
* Add real parsing for __declspec. It doesn't make much of a difference Eli Friedman2009-06-081-11/+43
| | | | | | at the moment because we ignore the result. llvm-svn: 73056
* Disallow exception specs on typedefs.Sebastian Redl2009-05-311-3/+8
| | | | llvm-svn: 72664
* AddInitializerToDecl needs to take a full expression.Anders Carlsson2009-05-301-1/+1
| | | | llvm-svn: 72640
* Reject incomplete types in exception specs.Sebastian Redl2009-05-291-18/+24
| | | | llvm-svn: 72580
* If a declarator group declares a type, make sure to add that declaration Eli Friedman2009-05-291-1/+2
| | | | | | to the DeclGroup. llvm-svn: 72559
* When we parse a tag specifier, keep track of whether that tagDouglas Gregor2009-05-281-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor the common code of 'ParseTypeofSpecifier' and ↵Argyrios Kyrtzidis2009-05-221-38/+22
| | | | | | | | 'ParseSizeofAlignofExpression' into a new 'ParseExprAfterTypeofSizeofAlignof' method. llvm-svn: 72256
* Parse typeof-specifier the same way as sizeof/alignof are parsed.Argyrios Kyrtzidis2009-05-221-48/+39
| | | | | | | | -Makes typeof consistent with sizeof/alignof -Fixes a bug when '>' is in a typeof expression, inside a template type param: A<typeof(x>1)> a; llvm-svn: 72255
* 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-5/+5
| | | | llvm-svn: 72210
* Implement a FIXME, we now pass in the locations of the braces for enums.Mike Stump2009-05-161-3/+3
| | | | llvm-svn: 71930
* Implement parsing for explicit instantiations of class templates, e.g.,Douglas Gregor2009-05-121-17/+11
| | | | | | | | | 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
* Refactor the parsing of declarations so that template declarations canDouglas Gregor2009-05-121-68/+89
| | | | | | | | | | parse just a single declaration and provide a reasonable diagnostic when the "only one declarator per template declaration" rule is violated. This eliminates some ugly, ugly hackery where we used to require thatn the layout of a DeclGroup of a single element be the same as the layout of a single declaration. llvm-svn: 71596
* Add parsing of friend specifiers.Anders Carlsson2009-05-061-0/+7
| | | | llvm-svn: 71067
* Rework the way we handle constructor decls to be less hacky and fix PR3948 ↵Anders Carlsson2009-04-301-10/+11
| | | | | | completely. llvm-svn: 70516
* Just because a declaration has the same name as its containing class doesn't ↵Anders Carlsson2009-04-291-10/+10
| | | | | | mean that it's a constructor. Fixes rdar://problem/6815988. llvm-svn: 70436
* Have the parser communicate the exception specification to the action.Sebastian Redl2009-04-291-6/+31
| | | | llvm-svn: 70389
* This is a pretty big cleanup for how invalid decl/type are handle.Chris Lattner2009-04-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This gets rid of a bunch of random InvalidDecl bools in sema, changing us to use the following approach: 1. When analyzing a declspec or declarator, if an error is found, we set a bit in Declarator saying that it is invalid. 2. Once the Decl is created by sema, we immediately set the isInvalid bit on it from what is in the declarator. From this point on, sema consistently looks at and sets the bit on the decl. This gives a very clear separation of concerns and simplifies a bunch of code. In addition to this, this patch makes these changes: 1. it renames DeclSpec::getInvalidType() -> isInvalidType(). 2. various "merge" functions no longer return bools: they just set the invalid bit on the dest decl if invalid. 3. The ActOnTypedefDeclarator/ActOnFunctionDeclarator/ActOnVariableDeclarator methods now set invalid on the decl returned instead of returning an invalid bit byref. 4. In SemaType, refering to a typedef that was invalid now propagates the bit into the resultant type. Stuff declared with the invalid typedef will now be marked invalid. 5. Various methods like CheckVariableDeclaration now return void and set the invalid bit on the decl they check. There are a few minor changes to tests with this, but the only major bad result is test/SemaCXX/constructor-recovery.cpp. I'll take a look at this next. llvm-svn: 70020
* fix the sizeof error recovery issue (sizeof-interface.m:attributeRuns)Chris Lattner2009-04-241-0/+1
| | | | | | | | by correctly propagating the fact that the type was invalid up to the attributeRuns decl, then returning an ExprError when attributeRuns is formed (like we do for normal declrefexprs). llvm-svn: 69998
* Fixup codegen for write barriers for block variables. Radar 6786715Mike Stump2009-04-211-1/+1
| | | | llvm-svn: 69642
* Make the implicit-int handling error recovery stuff handle C++Chris Lattner2009-04-141-20/+34
| | | | | | | | | | | | | | | | | | | nested name specifiers. Now we emit stuff like: t.cpp:8:13: error: unknown type name 'X' static foo::X P; ~~~~ ^ instead of: t.cpp:8:16: error: invalid token after top level declarator static foo::X P; ^ This is inspired by a really awful error message I got from g++ when I misspelt diag::kind as diag::Kind. llvm-svn: 69086
* refactor "implicit int error recovery" code out of Chris Lattner2009-04-141-62/+83
| | | | | | | ParseDeclarationSpecifiers into its own function, no functionality change. llvm-svn: 69083
* Fix a regression in a previous patch that broke implicit Chris Lattner2009-04-141-2/+4
| | | | | | int in a bitfield. Shantonu found this in a gcc testsuite file. llvm-svn: 69074
* fix a comment typo Sebastian noticed.Chris Lattner2009-04-121-1/+1
| | | | llvm-svn: 68921
* add support for handling C++'0x unified initializer syntaxChris Lattner2009-04-121-2/+2
| | | | | | to isValidAfterIdentifierInDeclarator, as suggested by Sebastian. llvm-svn: 68920
* Fix some C++ error recovery problems in init declarator parsingChris Lattner2009-04-121-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that I noticed working on other things. Instead of emitting: t2.cc:1:8: error: use of undeclared identifier 'g' int x(*g); ^ t2.cc:1:10: error: expected ')' int x(*g); ^ t2.cc:1:6: note: to match this '(' int x(*g); ^ We now only emit: t2.cc:1:7: warning: type specifier missing, defaults to 'int' int x(*g); ^ Note that the example in SemaCXX/nested-name-spec.cpp:f4 is still not great, we now produce both of: void f4(undef::C); // expected-error {{use of undeclared identifier 'undef'}} \ expected-error {{variable has incomplete type 'void'}} The second diagnostic should be silenced by something getting marked invalid. I don't plan to fix this though. llvm-svn: 68919
* mark the declspec as invalid when we recover instead of forcing to int,Chris Lattner2009-04-121-3/+3
| | | | | | this allows downstream diags to be properly silenced. llvm-svn: 68917
* Diagnose invalid uses of tagged types with a missing tag. For example, in:Chris Lattner2009-04-121-20/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement the first set of changes for PR3963 and rdar://6759604,Chris Lattner2009-04-121-4/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | which tries to do better error recovery when it is "obvious" that an identifier is a mis-typed typename. In this case, we try to parse it as a typename instead of as the identifier in a declarator, which gives us several options for better error recovery and immediately makes diagnostics more useful. For example, we now produce: t.c:4:8: error: unknown type name 'foo_t' static foo_t a = 4; ^ instead of: t.c:4:14: error: invalid token after top level declarator static foo_t a = 4; ^ Also, since we now parse "a" correctly, we make a decl for it, preventing later uses of 'a' from emitting things like: t.c:12:20: error: use of undeclared identifier 'a' int bar() { return a + b; } ^ I'd really appreciate any scrutiny possible on this, it is a tricky area. llvm-svn: 68911
* add fixit advice to an archiac ObjC issue.Chris Lattner2009-04-031-0/+1
| | | | llvm-svn: 68395
* fix a FIXME, providing accurate source range info for DeclStmt's. The endChris Lattner2009-04-021-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of the range is now the ';' location. For something like this: $ cat t2.c #define bool int void f(int x, int y) { bool b = !x && y; } We used to produce: $ clang-cc t2.c -ast-dump typedef char *__builtin_va_list; void f(int x, int y) (CompoundStmt 0x2201f10 <t2.c:3:22, line:5:1> (DeclStmt 0x2201ef0 <line:2:14> <---- 0x2201a20 "int b = (BinaryOperator 0x2201ed0 <line:4:10, col:16> 'int' '&&' (UnaryOperator 0x2201e90 <col:10, col:11> 'int' prefix '!' (DeclRefExpr 0x2201c90 <col:11> 'int' ParmVar='x' 0x2201a50)) (DeclRefExpr 0x2201eb0 <col:16> 'int' ParmVar='y' 0x2201e10))") Now we produce: $ clang-cc t2.c -ast-dump typedef char *__builtin_va_list; void f(int x, int y) (CompoundStmt 0x2201f10 <t2.c:3:22, line:5:1> (DeclStmt 0x2201ef0 <line:2:14, line:4:17> <------ 0x2201a20 "int b = (BinaryOperator 0x2201ed0 <col:10, col:16> 'int' '&&' (UnaryOperator 0x2201e90 <col:10, col:11> 'int' prefix '!' (DeclRefExpr 0x2201c90 <col:11> 'int' ParmVar='x' 0x2201a50)) (DeclRefExpr 0x2201eb0 <col:16> 'int' ParmVar='y' 0x2201e10))") llvm-svn: 68288
* Add code modification hints to various parsing-related diagnostics.Douglas Gregor2009-04-011-5/+9
| | | | | | | Plus, reword a extension warnings to avoid talking about "ISO C" when the extension might also be available in C++ or C++0x. llvm-svn: 68257
* Make parsing a semantic analysis a little more robust following SemaDouglas Gregor2009-04-011-11/+15
| | | | | | | | | | | | | | | | failures that involve malformed types, e.g., "typename X::foo" where "foo" isn't a type, or "std::vector<void>" that doens't instantiate properly. Similarly, be a bit smarter in our handling of ambiguities that occur in Sema::getTypeName, to eliminate duplicate error messages about ambiguous name lookup. This eliminates two XFAILs in test/SemaCXX, one of which was crying out to us, trying to tell us that we were producing repeated error messages. llvm-svn: 68251
* Parsing and AST representation for dependent template names that occurDouglas Gregor2009-03-311-2/+2
| | | | | | | | | | | within nested-name-specifiers, e.g., for the "apply" in typename MetaFun::template apply<T1, T2>::type At present, we can't instantiate these nested-name-specifiers, so our testing is sketchy. llvm-svn: 68081
* hoist some code for handling objc foreach construct out of Declaration ↵Chris Lattner2009-03-291-11/+9
| | | | | | | | processing into ParseForStatement. Merge two tests into one. llvm-svn: 68010
* hoist checks for ; and in out of ParseInitDeclaratorListAfterFirstDeclaratorChris Lattner2009-03-291-28/+28
| | | | | | into ParseSimpleDeclaration, and improve a diagnostic. llvm-svn: 68009
* Push DeclGroup much farther throughout the compiler. Now the variousChris Lattner2009-03-291-23/+36
| | | | | | | | | | | | | | | | | | | | | | | | | productions (except the already broken ObjC cases like @class X,Y;) in the parser that can produce more than one Decl return a DeclGroup instead of a Decl, etc. This allows elimination of the Decl::NextDeclarator field, and exposes various clients that should look at all decls in a group, but which were only looking at one (such as the dumper, printer, etc). These have been fixed. Still TODO: 1) there are some FIXME's in the code about potentially using DeclGroup for better location info. 2) ParseObjCAtDirectives should return a DeclGroup due to @class etc. 3) I'm not sure what is going on with StmtIterator.cpp, or if it can be radically simplified now. 4) I put a truly horrible hack in ParseTemplate.cpp. I plan to bring up #3/4 on the mailing list, but don't plan to tackle #1/2 in the short term. llvm-svn: 68002
* Introduce a new OpaquePtr<N> struct type, which is a simple POD wrapper for aChris Lattner2009-03-281-33/+36
| | | | | | | | | | | | | | | | | | | | pointer. Its purpose in life is to be a glorified void*, but which does not implicitly convert to void* or other OpaquePtr's with a different UID. Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>. Change the entire parser/sema interface to use DeclPtrTy instead of DeclTy*. This makes the C++ compiler enforce that these aren't convertible to other opaque types. We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc, but I don't plan to do that in the short term. The one outstanding known problem with this patch is that we lose the bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to bitmangle the success bit into the low bit of DeclPtrTy. I will rectify this with a subsequent patch. llvm-svn: 67952
* tidy whitespace.Chris Lattner2009-03-281-3/+4
| | | | llvm-svn: 67920
OpenPOWER on IntegriCloud