summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/MinimalAction.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Eliminate the "minimal" and printing parser actions, which only everDouglas Gregor2010-07-261-281/+0
| | | | | | | worked for C anyway. Also kills the -cc1 options -parse-noop and -parse-print-callbacks. llvm-svn: 109392
* Improve parser recovery when we encounter a dependent template nameDouglas Gregor2010-05-211-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that is missing the 'template' keyword, e.g., t->getAs<T>() where getAs is a member of an unknown specialization. C++ requires that we treat "getAs" as a value, but that would fail to parse since T is the name of a type. We would then fail at the '>', since a type cannot be followed by a '>'. This is a very common error for C++ programmers to make, especially since GCC occasionally allows it when it shouldn't (as does Visual C++). So, when we are in this case, we use tentative parsing to see if the tokens starting at "<" can only be parsed as a template argument list. If so, we produce a diagnostic with a fix-it that states that the 'template' keyword is needed: test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword is required to treat 'getAs' as a dependent template name t->getAs<T>(); ^ template This is just a start of this patch; I'd like to apply the same approach to everywhere that a template-id with dependent template name can be parsed. llvm-svn: 104406
* Migrate the responsibility for turning the receiver name in anDouglas Gregor2010-04-211-3/+18
| | | | | | | | | Objective-C class message expression into a type from the parser (which was doing so in two places) to Action::getObjCMessageKind() which, in the case of Sema, reduces the number of name lookups we need to perform. llvm-svn: 102026
* Introduce a parsing action to distinguish between class, instance, andDouglas Gregor2010-04-141-0/+14
| | | | | | | | super message sends in Objective-C. No actual functionality change here, but it provides a hook so that Sema can typo-correct the receiver in some cases. llvm-svn: 101207
* Make CXXScopeSpec invalid when incomplete, and propagate that into anyJeffrey Yasskin2010-04-081-4/+4
| | | | | | | Declarator that depends on it. This fixes several redundant errors and bad recoveries. llvm-svn: 100779
* Keep track of the source locations for each protocol reference inDouglas Gregor2010-01-161-0/+1
| | | | | | | | Objective-C classes, protocol definitions, forward protocol declarations, and categories. This information isn't actually used yet; that's coming next. llvm-svn: 93636
* Implement access declarations. Most of the work here is parsing them, whichJohn McCall2009-12-111-0/+1
| | | | | | | | | | | | 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
* Implement C++ [basic.lookup.classref]p3, which states how the typeDouglas Gregor2009-11-201-1/+1
| | | | | | | | | | | | name 'T' is looked up in the expression t.~T() Previously, we weren't looking into the type of "t", and therefore would fail when T actually referred to an injected-class-name. Fixes PR5530. llvm-svn: 89493
* Incremental progress on using declarations. Split UnresolvedUsingDecl intoJohn McCall2009-11-181-1/+2
| | | | | | | | | | two classes, one for typenames and one for values; this seems to have some support from Doug if not necessarily from the extremely-vague-on-this-point standard. Track the location of the 'typename' keyword in a using-typename decl. Make a new lookup result for unresolved values and deal with it in most places. llvm-svn: 89184
* Pass source locations of identifiers referenced by @class through ↵Ted Kremenek2009-11-171-1/+3
| | | | | | Action::ActOnForwardClassDeclaration(). llvm-svn: 89162
* Switch parsing of using declarations over to ParseUnqualifiedId.Douglas Gregor2009-11-041-4/+2
| | | | llvm-svn: 86027
* Parsing and semantic analysis for template-ids that name overloadedDouglas Gregor2009-11-031-3/+2
| | | | | | | | | | | | operators, e.g., operator+<int> which now works in declarators, id-expressions, and member access expressions. This commit only implements the non-dependent case, where we can resolve the template-id to an actual declaration. llvm-svn: 85966
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-22/+22
| | | | llvm-svn: 81346
* Rewrite of our handling of name lookup in C++ member access expressions, e.g.,Douglas Gregor2009-09-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Set the access specifier for using decls.Anders Carlsson2009-08-291-7/+8
| | | | llvm-svn: 80435
* When we know that we are parsing a class-name, implicitly construct aDouglas Gregor2009-08-261-1/+2
| | | | | | | | | | | | | | 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
* Improve support for out-of-line definitions of nested templates andDouglas Gregor2009-08-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make it possible for using decls to point to operators. Fixes PR4441.Anders Carlsson2009-06-271-0/+1
| | | | llvm-svn: 74362
* Parsing and AST support for using declarations, from John Thompson!Douglas Gregor2009-06-201-0/+16
| | | | llvm-svn: 73812
* teach -parse-noop about int128_t and friends.Chris Lattner2009-05-011-7/+14
| | | | llvm-svn: 70547
* Parsing and AST representation for dependent template names that occurDouglas Gregor2009-03-311-1/+1
| | | | | | | | | | | 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
* Improve the representation of template names in the AST. ThisDouglas Gregor2009-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 68074
* Push DeclGroup much farther throughout the compiler. Now the variousChris Lattner2009-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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-21/+21
| | | | | | | | | | | | | | | | | | | | 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
* fix "Comment#1" from PR3872Chris Lattner2009-03-241-1/+1
| | | | llvm-svn: 67625
* Convert a bunch of actions to smart pointers, and also bring ↵Sebastian Redl2009-03-151-1/+1
| | | | | | PrintParserCallbacks a bit more in line with reality. llvm-svn: 67029
* rename PrettyStackTraceDecl -> PrettyStackTraceActionsDecl.Chris Lattner2009-03-051-1/+1
| | | | | | | | | | | | | | | | 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. llvm-svn: 66153
* When the parser is live, print out the location and spelling of its current ↵Chris Lattner2009-03-051-0/+23
| | | | | | | | | | | | | | | | | 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. llvm-svn: 66148
* When parsing a function body, add it to the crash stack, giving us somethingChris Lattner2009-03-051-0/+15
| | | | | | | | | | | | | like: Stack dump: 0. t.c:5:10: in compound statement ('{}') 1. t.c:3:12: in compound statement ('{}') 2. t.c:3:12: parsing function body 'foo' 3. clang t.c Abort llvm-svn: 66118
* Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor2009-02-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. llvm-svn: 65467
* Start processing template-ids as types when the template-name refersDouglas Gregor2009-02-091-8/+5
| | | | | | | | | | | | | | | | | | | | | 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' :) llvm-svn: 64153
* Diagnose ambiguities in getTypeName. Fixes ↵Douglas Gregor2009-02-041-2/+2
| | | | | | http://llvm.org/bugs/show_bug.cgi?id=3475 llvm-svn: 63737
* Name change (isTypeName->getTypeName).Steve Naroff2009-01-281-2/+2
| | | | | | Since it doesn't return a bool, is shouldn't be prefixed with 'is'. llvm-svn: 63226
* Switch MinimalAction from new/delete'ing its TypeNameInfo to Chris Lattner2009-01-181-37/+56
| | | | | | | | allocating them from a recycling bump pointer allocator. This reduces malloc/free traffic of parse-noop (but no other mode), which makes sharking -parse-noop more meaningful. llvm-svn: 62460
* Ultrasimplistic sketch for the parsing of C++ template-ids. This won'tDouglas Gregor2008-12-181-0/+10
| | | | | | | | become useful or correct until we (1) parse template arguments correctly, (2) have some way to turn template-ids into types, declarators, etc., and (3) have a real representation of templates. llvm-svn: 61208
* Updated IdentifierResolver to deal with DeclarationNames. The names ofDouglas Gregor2008-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | C++ constructors, destructors, and conversion functions now have a FETokenInfo field that IdentifierResolver can access, so that these special names are handled just like ordinary identifiers. A few other Sema routines now use DeclarationNames instead of IdentifierInfo*'s. To validate this design, this code also implements parsing and semantic analysis for id-expressions that name conversion functions, e.g., return operator bool(); The new parser action ActOnConversionFunctionExpr takes the result of parsing "operator type-id" and turning it into an expression, using the IdentifierResolver with the DeclarationName of the conversion function. ActOnDeclarator pushes those conversion function names into scope so that the IdentifierResolver can find them, of course. llvm-svn: 59462
* Implement support for C++ nested-name-specifiers ('foo::bar::x') in the ↵Argyrios Kyrtzidis2008-11-081-2/+6
| | | | | | | | Parser side. No Sema functionality change, just the signatures of the Action/Sema methods. llvm-svn: 58913
* Add support for parsing and representing C++ constructor declarations.Douglas Gregor2008-10-311-0/+6
| | | | | | | | | | | | | | | Notes: - Constructors are never found by name lookup, so they'll never get pushed into any scope. Instead, they are stored as an OverloadedFunctionDecl in CXXRecordDecl for easy overloading. - There's a new action isCurrentClassName that determines whether an identifier is the name of the innermost class currently being defined; we use this to identify the declarator-id grammar rule that refers to a type-name. - MinimalAction does *not* support parsing constructors. - We now handle virtual and explicit function specifiers. llvm-svn: 58499
* "One" line fix for -parse-noop failure, "id" and several other thingsDaniel Dunbar2008-10-311-3/+7
| | | | | | | | were being treated as type names for non-Objective-C files. - Other lines are just because MinimalAction didn't have access to the LangOptions. llvm-svn: 58498
* Move AsmLabel into Declarator instead of just a parameter toDaniel Dunbar2008-08-051-2/+1
| | | | | | ActOnDeclarator. llvm-svn: 54353
* Add more Parser/Sema support for GCC asm-label extension.Daniel Dunbar2008-08-051-1/+2
| | | | | | | | | | | | | - ActOnDeclarator now takes an additional parameter which is the AsmLabel if used. Its unfortunate that this bubbles up this high, but we cannot just lump it in as an attribute without mistakenly *accepting* it as an attribute. - The actual asm-label itself is, however, encoded as an AsmLabelAttr on the FunctionDecl. - Slightly improved parser error recovery on malformed asm-labels. - CodeGen support still missing... llvm-svn: 54339
* Nico Weber:Ted Kremenek2008-08-041-3/+3
| | | | | | "the attached patch fixes some typos, 80 cols violations, etc. in comments." llvm-svn: 54328
* Wherever a type is used/returned from the Action module, use TypeTy instead ↵Argyrios Kyrtzidis2008-08-011-1/+1
| | | | | | | | of DeclTy or void. No functionality change. llvm-svn: 54265
* Pull protocol resolution of out ActOnStartClassInterface, this is also the Chris Lattner2008-07-261-5/+8
| | | | | | last client of the old ParseObjCProtocolReferences, so it also removes it. llvm-svn: 54094
* minor cleanup to the actions interface to pass around SmallVectorImpl insteadChris Lattner2008-07-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | of a specific smallvector size. Fix protocol lists to pass down proper location info, so we get diagnostics like this: t.m:3:35: error: cannot find protocol definition for 'NSCopying', referenced by 'NSWhatever' @interface NSWhatever : NSObject <NSCopying> ^ instead of this: t.m:3:44: error: cannot find protocol definition for 'NSCopying', referenced by 'NSWhatever' @interface NSWhatever : NSObject <NSCopying> ^ Add a new IdentifierLocPair typedef which is just a pair<IdentifierInfo*, SourceLocation> llvm-svn: 53883
* fix typoChris Lattner2008-07-211-1/+1
| | | | llvm-svn: 53848
* Two changes to Sema::LookupDecl() interface. Steve Naroff2008-04-021-1/+1
| | | | | | | | | | | (1) Remove IdLoc (it's never used). (2) Add a bool to enable/disable lazy builtin creaation (defaults to true). This enables us to use LookupDecl() in Sema::isTypeName(), which is also part of this commit. To make this work, I changed isTypeName() to be a non-const member function. I'm not happy with this, however I fiddled with making LookupDecl() and friends const and it got ugly pretty quickly. We can certainly add it back if/when someone has time to fiddle with it. For now, I thought this simplification was more important than retaining the const-ness. llvm-svn: 49087
* Make a major restructuring of the clang tree: introduce a top-levelChris Lattner2008-03-151-0/+136
lib dir and move all the libraries into it. This follows the main llvm tree, and allows the libraries to be built in parallel. The top level now enforces that all the libs are built before Driver, but we don't care what order the libs are built in. This speeds up parallel builds, particularly incremental ones. llvm-svn: 48402
OpenPOWER on IntegriCloud