summaryrefslogtreecommitdiffstats
path: root/clang/lib/Parse/ParseTemplate.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Rudimentary checking of template arguments against their correspondingDouglas Gregor2009-02-091-6/+17
| | | | | | | template parameters when performing semantic analysis of a template-id naming a class template specialization. llvm-svn: 64185
* Implement Sebastian's idea for simplifying our handling of the greater-than ↵Douglas Gregor2009-02-091-2/+6
| | | | | | operator/delimiter. Also, clean up after ourselves following a failed parse of a template-argument-list llvm-svn: 64166
* Eliminate TemplateArg so that we only have a single kind ofDouglas Gregor2009-02-091-18/+27
| | | | | | | | | | | | representation for template arguments. Also simplifies the interface for ActOnClassTemplateSpecialization and eliminates some annoying allocations of TemplateArgs. My attempt at smart pointers for template arguments lists is relatively lame. We can improve it once we're sure that we have the right representation for template arguments. llvm-svn: 64154
* Start processing template-ids as types when the template-name refersDouglas Gregor2009-02-091-23/+59
| | | | | | | | | | | | | | | | | | | | | 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
* Semantic checking for class template declarations andDouglas Gregor2009-02-061-4/+11
| | | | | | | | | | | | | | | redeclarations. For example, checks that a class template redeclaration has the same template parameters as previous declarations. Detangled class-template checking from ActOnTag, whose logic was getting rather convoluted because it tried to handle C, C++, and C++ template semantics in one shot. Made some inroads toward eliminating extraneous "declaration does not declare anything" errors by adding an "error" type specifier. llvm-svn: 63973
* Basic representation of C++ class templates, from Andrew Sutton.Douglas Gregor2009-02-041-19/+20
| | | | llvm-svn: 63750
* move library-specific diagnostic headers into library private dirs. ReduceChris Lattner2009-01-291-1/+1
| | | | | | redundant #includes. Patch by Anders Johnsen! llvm-svn: 63271
* Split the single monolithic DiagnosticKinds.def file into oneChris Lattner2009-01-271-1/+1
| | | | | | | | | .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! llvm-svn: 63111
* rename tok::annot_qualtypename -> tok::annot_typename, which is bothChris Lattner2009-01-061-1/+1
| | | | | | shorter and more accurate. The type name might not be qualified. llvm-svn: 61788
* TryAnnotateTypeOrScopeToken and TryAnnotateCXXScopeToken can Chris Lattner2009-01-051-2/+2
| | | | | | | only be called when they might be needed now, so make them assert that their current token is :: or identifier. llvm-svn: 61662
* Simplify some control flow and remove a call to TryAnnotateCXXScopeTokenChris Lattner2009-01-041-12/+11
| | | | | | | that isn't doing what is desired. It was annotating the current token not the 'next' token. This code should be fixed. llvm-svn: 61656
* Keep track of template arguments when we parse them. Right now, we don't ↵Douglas Gregor2008-12-241-51/+94
| | | | | | actually do anything with the template arguments, but they'll be used to create template declarations llvm-svn: 61413
* Ultrasimplistic sketch for the parsing of C++ template-ids. This won'tDouglas Gregor2008-12-181-2/+106
| | | | | | | | 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
* Use a scoped object to manage entry/exit from a parser scope rather than ↵Douglas Gregor2008-12-101-4/+1
| | | | | | explicitly calling EnterScope/ExitScope llvm-svn: 60830
* Kick out the proof-of-concept ASTOwner and replace it with ASTOwningResultSebastian Redl2008-12-091-2/+1
| | | | llvm-svn: 60791
* Consistently use smart pointers for stmt and expr nodes in parser local ↵Sebastian Redl2008-12-091-3/+4
| | | | | | variables. llvm-svn: 60761
* Representation of template type parameters and non-type templateDouglas Gregor2008-12-051-1/+1
| | | | | | | | | | | | | | | parameters, with some semantic analysis: - Template parameters are introduced into template parameter scope - Complain about template parameter shadowing (except in Microsoft mode) Note that we leak template parameter declarations like crazy, a problem we'll remedy once we actually create proper declarations for templates. Next up: dependent types and value-dependent/type-dependent expressions. llvm-svn: 60597
* A little more scaffolding for parsing templates:Douglas Gregor2008-12-021-38/+44
| | | | | | | | | - Template parameter scope to hold the template parameters - Template parameter context for parsing declarators - Actions for template type parameters and non-type template parameters llvm-svn: 60387
* Basic support for parsing templates, from Andrew SuttonDouglas Gregor2008-12-011-0/+288
llvm-svn: 60384
OpenPOWER on IntegriCloud