aboutsummaryrefslogtreecommitdiff
path: root/lib/Parse/ParseDecl.cpp
AgeCommit message (Collapse)Author
2009-05-12Implement parsing for explicit instantiations of class templates, e.g.,Douglas Gregor
template class X<int>; This also cleans up the propagation of template information through declaration parsing, which is used to improve some diagnostics. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71608 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-12Refactor the parsing of declarations so that template declarations canDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71596 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-06Add parsing of friend specifiers.Anders Carlsson
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71067 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-30Rework the way we handle constructor decls to be less hacky and fix PR3948 ↵Anders Carlsson
completely. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70516 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-29Just because a declaration has the same name as its containing class doesn't ↵Anders Carlsson
mean that it's a constructor. Fixes rdar://problem/6815988. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70436 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-29Have the parser communicate the exception specification to the action.Sebastian Redl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70389 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-25This is a pretty big cleanup for how invalid decl/type are handle.Chris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70020 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-24fix the sizeof error recovery issue (sizeof-interface.m:attributeRuns)Chris Lattner
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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69998 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-21Fixup codegen for write barriers for block variables. Radar 6786715Mike Stump
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69642 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-14Make the implicit-int handling error recovery stuff handle C++Chris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69086 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-14refactor "implicit int error recovery" code out of Chris Lattner
ParseDeclarationSpecifiers into its own function, no functionality change. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69083 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-14Fix a regression in a previous patch that broke implicit Chris Lattner
int in a bitfield. Shantonu found this in a gcc testsuite file. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69074 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-12fix a comment typo Sebastian noticed.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68921 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-12add support for handling C++'0x unified initializer syntaxChris Lattner
to isValidAfterIdentifierInDeclarator, as suggested by Sebastian. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68920 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-12Fix some C++ error recovery problems in init declarator parsingChris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68919 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-12mark the declspec as invalid when we recover instead of forcing to int,Chris Lattner
this allows downstream diags to be properly silenced. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68917 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-12Diagnose invalid uses of tagged types with a missing tag. For example, in:Chris Lattner
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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68914 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-12Implement the first set of changes for PR3963 and rdar://6759604,Chris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68911 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-03add fixit advice to an archiac ObjC issue.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68395 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-02fix a FIXME, providing accurate source range info for DeclStmt's. The endChris Lattner
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))") git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68288 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-01Add code modification hints to various parsing-related diagnostics.Douglas Gregor
Plus, reword a extension warnings to avoid talking about "ISO C" when the extension might also be available in C++ or C++0x. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68257 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-01Make parsing a semantic analysis a little more robust following SemaDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68251 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-31Parsing and AST representation for dependent template names that occurDouglas Gregor
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68081 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-29hoist some code for handling objc foreach construct out of Declaration ↵Chris Lattner
processing into ParseForStatement. Merge two tests into one. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68010 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-29hoist checks for ; and in out of ParseInitDeclaratorListAfterFirstDeclaratorChris Lattner
into ParseSimpleDeclaration, and improve a diagnostic. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68009 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-29Push DeclGroup much farther throughout the compiler. Now the variousChris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68002 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-28Introduce a new OpaquePtr<N> struct type, which is a simple POD wrapper for aChris Lattner
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67952 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-28tidy whitespace.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67920 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-27Initial implementation of parsing, semantic analysis, and templateDouglas Gregor
instantiation for C++ typename-specifiers such as typename T::type The parsing of typename-specifiers is relatively easy thanks to annotation tokens. When we see the "typename", we parse the typename-specifier and produce a typename annotation token. There are only a few places where we need to handle this. We currently parse the typename-specifier form that terminates in an identifier, but not the simple-template-id form, e.g., typename T::template apply<U, V> Parsing of nested-name-specifiers has a similar problem, since at this point we don't have any representation of a class template specialization whose template-name is unknown. Semantic analysis is only partially complete, with some support for template instantiation that works for simple examples. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67875 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-27Fix rdar://6719156 - clang should emit a better error when blocks are ↵Chris Lattner
disabled but are used anyway by changing blocks from being disabled in the parser to being disabled in Sema. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67816 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-26Simplify CXXScopeSpec a lot. No more weird SmallVector-like hacks hereDouglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67800 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-25Pass access specifiers through to member classes and member enums.Douglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67710 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-25Fix parsing of template classes prefixed by nested-name-specifiersDouglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67685 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-24Parse deleted function definitions and hook them up to Doug's machinery.Sebastian Redl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67653 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-24random cleanups.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67624 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-23Recognize rvalue references in C++03, but complain about them. This leads to ↵Sebastian Redl
far better error recovery. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67495 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-19Introduce a representation for types that we referred to via aDouglas Gregor
qualified name, e.g., foo::x so that we retain the nested-name-specifier as written in the source code and can reproduce that qualified name when printing the types back (e.g., in diagnostics). This is PR3493, which won't be complete until finished the other tasks mentioned near the end of this commit. The parser's representation of nested-name-specifiers, CXXScopeSpec, is now a bit fatter, because it needs to contain the scopes that precede each '::' and keep track of whether the global scoping operator '::' was at the beginning. For example, we need to keep track of the leading '::', 'foo', and 'bar' in ::foo::bar::x The Action's CXXScopeTy * is no longer a DeclContext *. It's now the opaque version of the new NestedNameSpecifier, which contains a single component of a nested-name-specifier (either a DeclContext * or a Type *, bitmangled). The new sugar type QualifiedNameType composes a sequence of NestedNameSpecifiers with a representation of the type we're actually referring to. At present, we only build QualifiedNameType nodes within Sema::getTypeName. This will be extended to other type-constructing actions (e.g., ActOnClassTemplateId). Also on the way: QualifiedDeclRefExprs will also store a sequence of NestedNameSpecifiers, so that we can print out the property nested-name-specifier. I expect to also use this for handling dependent names like Fibonacci<I - 1>::value. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67265 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-15Parser support for rvalue references.Sebastian Redl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67033 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-15Convert a bunch of actions to smart pointers, and also bring ↵Sebastian Redl
PrintParserCallbacks a bit more in line with reality. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67029 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-11Add parser support for static_assert.Anders Carlsson
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66661 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-09Implement property '.' notation on Factory/Class objects. Parser changes ↵Steve Naroff
aren't very pretty:-( This fixes <rdar://problem/6496506> Implement class setter/getter for properties. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66465 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-06Clean up some error messages with anonymous structs/unions and member ↵Douglas Gregor
declaration parsing. Fixes PR3680 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66305 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-05rename PrettyStackTraceDecl -> PrettyStackTraceActionsDecl.Chris Lattner
Introduce a new PrettyStackTraceDecl. Use it to add the top level LLVM IR generation stuff in Backend.cpp to stack traces. We now get crashes like: Stack dump: 0. Program arguments: clang t.c -emit-llvm 1. <eof> parser at end of file 2. t.c:1:5: LLVM IR generation of declaration 'a' Abort for IR generation crashes. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66153 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-05Include struct context info for parser/sema crashes. ThisChris Lattner
gives us: Stack dump: 0. using-directive.cpp:26:16: in compound statement ('{}') 1. using-directive.cpp:26:16: parsing function body 'A::K1::foo' 2. using-directive.cpp:25:3: parsing struct/union/class body 'A::K1' 3. using-directive.cpp:5:1: parsing namespace 'A' 4. clang using-directive.cpp Abort for code like: namespace A { ... class K1 { void foo() { <<crash>> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66124 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-05Include information about compound statements when crashing in sema or theChris Lattner
parser. For example, we now print out: 0. t.c:5:10: in compound statement {} 1. t.c:3:12: in compound statement {} 2. clang t.c -fsyntax-only git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66108 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27cleanupChris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65646 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-25Implementing parsing of template-ids as class-names, so that we canDouglas Gregor
derive from a class template specialization, e.g., class B : public A<int> { }; git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65488 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-25Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor
std::vector<int>::allocator_type When we parse a template-id that names a type, it will become either a template-id annotation (which is a parsed representation of a template-id that has not yet been through semantic analysis) or a typename annotation (where semantic analysis has resolved the template-id to an actual type), depending on the context. We only produce a type in contexts where we know that we only need type information, e.g., in a type specifier. Otherwise, we create a template-id annotation that can later be "upgraded" by transforming it into a typename annotation when the parser needs a type. This occurs, for example, when we've parsed "std::vector<int>" above and then see the '::' after it. However, it means that when writing something like this: template<> class Outer::Inner<int> { ... }; We have two tokens to represent Outer::Inner<int>: one token for the nested name specifier Outer::, and one template-id annotation token for Inner<int>, which will be passed to semantic analysis to define the class template specialization. Most of the churn in the template tests in this patch come from an improvement in our error recovery from ill-formed template-ids. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65467 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-18Update Parser::ParseTypeName to return a TypeResult, which also tellsDouglas Gregor
us whether there was an error in trying to parse a type-name (type-id in C++). This allows propagation of errors further in the compiler, suppressing more bogus error messages. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64922 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-18Allow "overloadable" functions in C to be declared as variadic withoutDouglas Gregor
any named parameters, e.g., this is accepted in C: void f(...) __attribute__((overloadable)); although this would be rejected: void f(...); To do this, moved the checking of the "ellipsis without any named arguments" condition from the parser into Sema (where it belongs anyway). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64902 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2025-05-08 02:45:43 +0000