aboutsummaryrefslogtreecommitdiff
path: root/lib/Parse/Parser.cpp
AgeCommit message (Collapse)Author
2009-05-12Parser::ParseDeclarationOrFunctionDefinition no longer needs to acceptDouglas Gregor
template parameters. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71598 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-04-26Implement function-try-blocks. However, there's a very subtle bug that I ↵Sebastian Redl
can't track down. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70155 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 some more code modification hintsDouglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68261 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-04-01Parsing, semantic analysis, and template instantiation for typenameDouglas Gregor
specifiers that terminate in a simple-template-id, e.g., typename MetaFun::template apply<T1, T2> Also, implement template instantiation for dependent nested-name-specifiers that involve unresolved identifiers, e.g., typename T::type::type git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68166 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-30Improve the representation of template names in the AST. ThisDouglas Gregor
representation handles the various ways in which one can name a template, including unqualified references ("vector"), qualified references ("std::vector"), and dependent template names ("MetaFun::template apply"). One immediate effect of this change is that the representation of nested-name-specifiers in type names for class template specializations (e.g., std::vector<int>) is more accurate. Rather than representing std::vector<int> as std::(vector<int>) we represent it as (std::vector)<int> which more closely follows the C++ grammar. Additionally, templates are no longer represented as declarations (DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new OpaquePtr type (TemplateTy) that holds the representation of a TemplateName. This will simplify the handling of dependent template-names, once we get there. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68074 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-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-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-26Handle parsing of templates in member declarations. Pass the AccessSpecifier ↵Anders Carlsson
all the way down to ActOnClassTemplate. Doug, Sebastian: Plz review! :) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67723 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-25Improve handling of base initializers. We now parse initializers in out of ↵Anders Carlsson
line decls, such as: class C { C() { } int a; }; C::C() : a(10) { } We also diagnose when initializers are used on declarations that aren't constructors: t.cpp:1:10: error: only constructors take base initializers void f() : a(10) { } ^ Doug and/or Sebastian: I'd appreciate a review, especially the nested-name-spec test results (from the looks of it we now match gcc in that test.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67672 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-23Implement '#pragma unused'.Ted Kremenek
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67569 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-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-05fix eof checkChris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66149 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-05When the parser is live, print out the location and spelling of its current ↵Chris Lattner
token. For example: Stack dump: 0. Program arguments: clang t.cpp 1. t.cpp:4:8: current parser token: ';' 2. t.cpp:3:1: parsing struct/union/class body 'x' Abort It is weird that the parser is always "underneath" any parse context actions, but the parser is created first. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66148 91177308-0d34-0410-b5e6-96231b3b80d8
2009-03-05Simplify the interface to ParseFunctionStatementBody to not take Chris Lattner
locations that are the current tok loc. Note that inline C++ methods have a big fixme that could cause a crash. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66113 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27cleanupChris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65645 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27Clean up and document code modification hints.Douglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65641 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-27change a diagnostic message from something pedantically correct butChris Lattner
useless to something more vague but hopefully more clear. rdar://6624173 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65639 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-26Introduce code modification hints into the diagnostics system. When weDouglas Gregor
know how to recover from an error, we can attach a hint to the diagnostic that states how to modify the code, which can be one of: - Insert some new code (a text string) at a particular source location - Remove the code within a given range - Replace the code within a given range with some new code (a text string) Right now, we use these hints to annotate diagnostic information. For example, if one uses the '>>' in a template argument in C++98, as in this code: template<int I> class B { }; B<1000 >> 2> *b1; we'll warn that the behavior will change in C++0x. The fix is to insert parenthese, so we use code insertion annotations to illustrate where the parentheses go: test.cpp:10:10: warning: use of right-shift operator ('>>') in template argument will require parentheses in C++0x B<1000 >> 2> *b1; ^ ( ) Use of these annotations is partially implemented for HTML diagnostics, but it's not (yet) producing valid HTML, which may be related to PR2386, so it has been #if 0'd out. In this future, we could consider hooking this mechanism up to the rewriter to actually try to fix these problems during compilation (or, after a compilation whose only errors have fixes). For now, however, I suggest that we use these code modification hints whenever we can, so that we get better diagnostics now and will have better coverage when we find better ways to use this information. This also fixes PR3410 by placing the complaint about missing tokens just after the previous token (rather than at the location of the next token). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 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-09Start processing template-ids as types when the template-name refersDouglas Gregor
to a class template. For example, the template-id 'vector<int>' now has a nice, sugary type in the type system. What we can do now: - Parse template-ids like 'vector<int>' (where 'vector' names a class template) and form proper types for them in the type system. - Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly, using (sadly) a bool in the parser to tell it whether '>' should be treated as an operator or not. This is a baby-step, with major problems and limitations: - There are currently two ways that we handle template arguments (whether they are types or expressions). These will be merged, and, most likely, TemplateArg will disappear. - We don't have any notion of the declaration of class template specializations or of template instantiations, so all template-ids are fancy names for 'int' :) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64153 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-09Implement Declarator::getSourceRange().Sebastian Redl
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64151 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-05Put the invalid flag of OwningResult into the Action pointer.Sebastian Redl
This shrinks OwningResult by one pointer. Since it is no longer larger than OwningPtr, merge the two. This leads to simpler client code and speeds up my benchmark by 2.7%. For some reason, this exposes a previously hidden bug, causing a regression in SemaCXX/condition.cpp. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63867 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-04Basic representation of C++ class templates, from Andrew Sutton.Douglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63750 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-04Diagnose ambiguities in getTypeName. Fixes ↵Douglas Gregor
http://llvm.org/bugs/show_bug.cgi?id=3475 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63737 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-29move library-specific diagnostic headers into library private dirs. ReduceChris Lattner
redundant #includes. Patch by Anders Johnsen! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63271 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-28Name change (isTypeName->getTypeName).Steve Naroff
Since it doesn't return a bool, is shouldn't be prefixed with 'is'. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63226 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-27Split the single monolithic DiagnosticKinds.def file into oneChris Lattner
.def file for each library. This means that adding a diagnostic to sema doesn't require all the other libraries to be rebuilt. Patch by Anders Johnsen! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63111 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-23Handle any undeclared parameters in a K&R-style function with aDouglas Gregor
special action, inside function prototype scope. This avoids confusion when we try to inject these parameters into the scope of the function body before the function itself has been added to the surrounding scope. Fixes <rdar://problem/6097326>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@62849 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-18Rename move_convert to move_arg and move_res. The new names are less ↵Sebastian Redl
misleading (and shorter). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@62466 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-09When we see a reference to a struct, class, or union like "struct X"Douglas Gregor
that is neither a definition nor a forward declaration and where X has not yet been declared as a tag, introduce a declaration into the appropriate scope (which is likely *not* to be the current scope). The rules for the placement of the declaration differ slightly in C and C++, so we implement both and test the various corner cases. This implementation isn't 100% correct due to some lingering issues with the function prototype scope (for a function parameter list) not being the same scope as the scope of the function definition. Testcase is FIXME'd; this probably isn't an important issue. Addresses <rdar://problem/6484805>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@62014 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-06rename MaybeParseCXXScopeSpecifier -> ParseOptionalCXXScopeSpecifier and Chris Lattner
MaybeParseTypeSpecifier -> ParseOptionalTypeSpecifier. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61796 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-06rename tok::annot_qualtypename -> tok::annot_typename, which is bothChris Lattner
shorter and more accurate. The type name might not be qualified. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61788 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-05remove optimization to avoid looking ahead for cases like ::foo. ThisChris Lattner
isn't worth the complexity and the code already does a ton of lookahead. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61671 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-05Rearrange some code in TryAnnotateTypeOrScopeToken to make it Chris Lattner
early exit for C and avoid template lookup for C. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61667 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-05TryAnnotateTypeOrScopeToken and TryAnnotateCXXScopeToken can Chris Lattner
only be called when they might be needed now, so make them assert that their current token is :: or identifier. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61662 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-05ParseCXXSimpleTypeSpecifier can only be called on things that areChris Lattner
verified to be simple type specifiers, so there is no need for it to call TryAnnotateTypeOrScopeToken. Make MaybeParseCXXScopeSpecifier reject ::new and ::delete with a hard error now that it may never be transitively called in a context where these are legal. This allows me to start disentangling things more. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61659 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-05sink a call to TryAnnotateCXXScopeToken down into theChris Lattner
applicable cases in ParseDeclarationSpecifiers. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61657 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-04my previous patch caused sema to drop the global qualifier, makeChris Lattner
sure to pass it down. This makes the code a bit gross, I will clean it up in subsequent commits. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61650 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-04use early exits to reduce nesting.Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61642 91177308-0d34-0410-b5e6-96231b3b80d8
2008-12-30Parser support for C++ using directives, from Piotr RakDouglas Gregor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61486 91177308-0d34-0410-b5e6-96231b3b80d8
2008-12-24Keep track of template arguments when we parse them. Right now, we don't ↵Douglas Gregor
actually do anything with the template arguments, but they'll be used to create template declarations git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61413 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2025-05-08 14:54:09 +0000