summaryrefslogtreecommitdiffstats
path: root/clang/docs/InternalsManual.html
diff options
context:
space:
mode:
authorDouglas Gregor <dgregor@apple.com>2009-02-25 19:37:18 +0000
committerDouglas Gregor <dgregor@apple.com>2009-02-25 19:37:18 +0000
commit7f74112756f6cada66df1237b86788e71401bae5 (patch)
tree2c7296f80da41208e16e683772df61b8d7ab6837 /clang/docs/InternalsManual.html
parent22a87f94a9259c9295dc22d3d7e4b6c54e242f19 (diff)
downloadbcm5719-llvm-7f74112756f6cada66df1237b86788e71401bae5.tar.gz
bcm5719-llvm-7f74112756f6cada66df1237b86788e71401bae5.zip
Implement parsing of nested-name-specifiers that involve template-ids, e.g.,
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
Diffstat (limited to 'clang/docs/InternalsManual.html')
-rw-r--r--clang/docs/InternalsManual.html10
1 files changed, 4 insertions, 6 deletions
diff --git a/clang/docs/InternalsManual.html b/clang/docs/InternalsManual.html
index 7b6d201053c..9250fd1dd77 100644
--- a/clang/docs/InternalsManual.html
+++ b/clang/docs/InternalsManual.html
@@ -628,12 +628,10 @@ by the Action::ActOnCXXGlobalScopeSpecifier and
Action::ActOnCXXNestedNameSpecifier callbacks. In the case of Sema, this is a
<tt>DeclContext*</tt>.</li>
-<li><b>tok::annot_template_id</b>: This annotation token represents a C++
-template-id such as "foo&lt;int, 4&gt;", which may refer to a function or type
-depending on whether foo is a function template or class template. The
-AnnotationValue pointer is a pointer to a malloc'd TemplateIdAnnotation object.
-FIXME: I don't think the parsing logic is right for this. Shouldn't type
-templates be turned into annot_typename??</li>
+<li><b>tok::annot_template_id</b>: This annotation token represents a
+C++ template-id such as "foo&lt;int, 4&gt;", where "foo" is the name
+of a template. The AnnotationValue pointer is a pointer to a malloc'd
+TemplateIdAnnotation object. Depending on the context, a parsed template-id that names a type might become a typename annotation token (if all we care about is the named type, e.g., because it occurs in a type specifier) or might remain a template-id token (if we want to retain more source location information or produce a new type, e.g., in a declaration of a class template specialization). template-id annotation tokens that refer to a type can be "upgraded" to typename annotation tokens by the parser.</li>
</ol>
OpenPOWER on IntegriCloud