summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* When placing an annotation token over an existing annotation token, make ↵Sebastian Redl2010-02-081-1/+1
| | | | | | sure that the new token's range extends to the end of the old token. Assert that in AnnotateCachedTokens. Fixes PR6248. llvm-svn: 95555
* Reimplement constructor declarator parsing to cope with template-idsDouglas Gregor2010-01-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make sure to give an error for template argument lists followed by junk.Eli Friedman2009-12-271-2/+4
| | | | llvm-svn: 92177
* Second half of r91023, saving files is good.Chris Lattner2009-12-101-0/+1
| | | | llvm-svn: 91024
* spread 'const' love to some variables. this considerably reduces the amount ↵Nuno Lopes2009-12-101-1/+1
| | | | | | of dirty data around. llvm-svn: 91002
* Remove remaining VISIBILITY_HIDDEN from anonymous namespaces.Benjamin Kramer2009-11-281-2/+1
| | | | llvm-svn: 90044
* Added rudimentary C++0x attribute support.Alexis Hunt2009-11-211-0/+4
| | | | | | | | | | | | | | 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
* Implement C++ [temp.param]p2 correctly, looking ahead when we see aDouglas Gregor2009-11-211-5/+35
| | | | | | | "typename" parameter to distinguish between non-type and type template parameters. Fixes the actual bug in PR5559. llvm-svn: 89532
* Cope with extraneous "template" keyword when providing an out-of-lineDouglas Gregor2009-11-201-1/+2
| | | | | | definition of a member template (or a member thereof). Fixes PR5566. llvm-svn: 89512
* Remove an overly-eager assertion when replacing tokens with anDouglas Gregor2009-11-121-16/+17
| | | | | | | | | | | annotation token, because some of the tokens we're annotating might not be in the set of cached tokens (we could have consumed them unconditionally). Also, move the tentative parsing from ParseTemplateTemplateArgument into the one caller that needs it, improving recovery. llvm-svn: 86904
* Introduce a new representation for template templateDouglas Gregor2009-11-111-73/+90
| | | | | | | | | | | | | | | | | | | | | | | | | parameters. Rather than storing them as either declarations (for the non-dependent case) or expressions (for the dependent case), we now (always) store them as TemplateNames. The primary change here is to add a new kind of TemplateArgument, which stores a TemplateName. However, making that change ripples to every switch on a TemplateArgument's kind, also affecting TemplateArgumentLocInfo/TemplateArgumentLoc, default template arguments for template template parameters, type-checking of template template arguments, etc. This change is light on testing. It should fix several pre-existing problems with template template parameters, such as: - the inability to use dependent template names as template template arguments - template template parameter default arguments cannot be instantiation However, there are enough pieces missing that more implementation is required before we can adequately test template template parameters. llvm-svn: 86777
* Silence warning.Benjamin Kramer2009-11-101-1/+1
| | | | llvm-svn: 86719
* Improve parsing of template arguments to lay the foundation forDouglas Gregor2009-11-101-38/+97
| | | | | | | | | | | | | | | | | | | | | | 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
* Properly replace (cxxscope, template-id) annotation tokens with aDouglas Gregor2009-11-041-5/+4
| | | | | | single typename annotation token when backtracing. Fixes PR5350. llvm-svn: 86034
* Change our basic strategy for avoiding deprecation warnings when the decl useJohn McCall2009-11-041-3/+6
| | | | | | | | | | | | 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
* Implement support for parsing dependent template-ids that refer toDouglas Gregor2009-11-041-5/+12
| | | | | | | | overloaded operators, e.g., p->template operator+<T>() llvm-svn: 85989
* Improved fix for PR3844, which recovers better for class templateDouglas Gregor2009-10-301-1/+5
| | | | | | partial specializations and explicit instantiations of non-templates. llvm-svn: 85620
* Remove tabs, and whitespace cleanups.Mike Stump2009-09-091-81/+81
| | | | llvm-svn: 81346
* Parse extern templates, pass that information all the way to Sema,Douglas Gregor2009-09-041-5/+9
| | | | | | then drop it on the floor. llvm-svn: 80989
* Keep track of the template parameter depth properly when we haveDouglas Gregor2009-08-241-5/+32
| | | | | | | | | | member templates declared inside other templates. This allows us to match out-of-line definitions of member function templates within class templates to the declarations within the class template. We still can't handle out-of-line definitions for member class templates, however. llvm-svn: 79955
* Initial support for parsing and representation of member function templates.Douglas Gregor2009-08-201-0/+6
| | | | llvm-svn: 79570
* Fix a typo in a variable nameDouglas Gregor2009-08-201-3/+3
| | | | llvm-svn: 79558
* sp.John McCall2009-07-311-1/+1
| | | | llvm-svn: 77656
* Implement support for out-of-line definitions of the class members of classDouglas Gregor2009-07-221-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | templates, e.g., template<typename T> struct Outer { struct Inner; }; template<typename T> struct Outer<T>::Inner { // ... }; Implementing this feature required some extensions to ActOnTag, which now takes a set of template parameter lists, and is the precursor to removing the ActOnClassTemplate function from the parser Action interface. The reason for this approach is simple: the parser cannot tell the difference between a class template definition and the definition of a member of a class template; both have template parameter lists, and semantic analysis determines what that template parameter list means. There is still some cleanup to do with ActOnTag and ActOnClassTemplate. This commit provides the basic functionality we need, however. llvm-svn: 76820
* fix PR4452, a crash on invalid. The error recovery is still terrible in ↵Chris Lattner2009-06-261-6/+21
| | | | | | | | this case but at least we don't crash :) llvm-svn: 74264
* Make sure that the template parameter lists get from the parser down to ↵Douglas Gregor2009-06-241-1/+1
| | | | | | ActOnFunctionDeclarator for function template definitions llvm-svn: 74040
* Start propagating template parameter lists to the right places toDouglas Gregor2009-06-231-1/+2
| | | | | | | handle function templates. There's no actual code for function templates yet, but at least we complain about typedef templates. llvm-svn: 74021
* Rework the way we track which declarations are "used" duringDouglas Gregor2009-06-221-2/+2
| | | | | | | | | | | | | | | | | | | | | compilation, and (hopefully) introduce RAII objects for changing the "potentially evaluated" state at all of the necessary places within Sema and Parser. Other changes: - Set the unevaluated/potentially-evaluated context appropriately during template instantiation. - We now recognize three different states while parsing or instantiating expressions: unevaluated, potentially evaluated, and potentially potentially evaluated (for C++'s typeid). - When we're in a potentially potentially-evaluated context, queue up MarkDeclarationReferenced calls in a stack. For C++ typeid expressions that are potentially evaluated, we will play back these MarkDeclarationReferenced calls when we exit the corresponding potentially potentially-evaluated context. - Non-type template arguments are now parsed as constant expressions, so they are not potentially-evaluated. llvm-svn: 73899
* Address more comments from Doug.Anders Carlsson2009-06-121-6/+9
| | | | llvm-svn: 73267
* Parse support for C++0x type parameter packs.Anders Carlsson2009-06-121-5/+14
| | | | llvm-svn: 73247
* 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-3/+3
| | | | llvm-svn: 72210
* Implement parsing for explicit instantiations of class templates, e.g.,Douglas Gregor2009-05-121-13/+31
| | | | | | | | | 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-8/+108
| | | | | | | | | | 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
* fix a FIXME, providing accurate source range info for DeclStmt's. The endChris Lattner2009-04-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make parsing a semantic analysis a little more robust following SemaDouglas Gregor2009-04-011-12/+5
| | | | | | | | | | | | | | | | 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-6/+6
| | | | | | | | | | | 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-12/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+6
| | | | | | | | | | | | | | | | | | | | | | | | | 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-23/+22
| | | | | | | | | | | | | | | | | | | | 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
* Handle parsing of templates in member declarations. Pass the AccessSpecifier ↵Anders Carlsson2009-03-261-2/+3
| | | | | | | | all the way down to ActOnClassTemplate. Doug, Sebastian: Plz review! :) llvm-svn: 67723
* Clean up and document code modification hints.Douglas Gregor2009-02-271-1/+2
| | | | llvm-svn: 65641
* Introduce code modification hints into the diagnostics system. When weDouglas Gregor2009-02-261-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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). llvm-svn: 65570
* Cope with use of the token '>>' inside a template argument list, e.g.,Douglas Gregor2009-02-251-5/+15
| | | | | | | | | | | | | vector<vector<double>> Matrix; In C++98/03, this token always means "right shift". However, if we're in a context where we know that it can't mean "right shift", provide a friendly reminder to put a space between the two >'s and then treat it as two >'s as part of recovery. In C++0x, this token is always broken into two '>' tokens. llvm-svn: 65484
* Implement parsing of nested-name-specifiers that involve template-ids, e.g.,Douglas Gregor2009-02-251-14/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update Parser::ParseTypeName to return a TypeResult, which also tellsDouglas Gregor2009-02-181-3/+7
| | | | | | | | 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. llvm-svn: 64922
* Implement basic parsing and semantic analysis for explicitDouglas Gregor2009-02-171-50/+103
| | | | | | | | | | | | | | | | | | specialization of class templates, e.g., template<typename T> class X; template<> class X<int> { /* blah */ }; Each specialization is a different *Decl node (naturally), and can have different members. We keep track of forward declarations and definitions as for other class/struct/union types. This is only the basic framework: we still have to deal with checking the template headers properly, improving recovery when there are failures, handling nested name specifiers, etc. llvm-svn: 64848
* Fix a problem with bogus template shadowing warningsDouglas Gregor2009-02-101-3/+6
| | | | llvm-svn: 64230
* Implement parsing, semantic analysis and ASTs for default templateDouglas Gregor2009-02-101-21/+36
| | | | | | | | | arguments. This commit covers checking and merging default template arguments from previous declarations, but it does not cover the actual use of default template arguments when naming class template specializations. llvm-svn: 64229
* Teach the type-id/expression disambiguator about differentDouglas Gregor2009-02-101-1/+1
| | | | | | | | | | | | | | | | | disambiguation contexts, so that we properly parse template arguments such as A<int()> as type-ids rather than as expressions. Since this can be confusing (especially when the template parameter is a non-type template parameter), we try to give a friendly error message. Almost, eliminate a redundant error message (that should have been a note) and add some ultra-basic checks for non-type template arguments. llvm-svn: 64189
OpenPOWER on IntegriCloud