Hello.
clang AST is missing nodes able to represent various kinds of instantiations and/or specializations of (member of class) templates, such as the following:
Hello Enea,
Hello.
clang AST is missing nodes able to represent various kinds of
instantiations and/or specializations of (member of class) templates,
such as the following:============================================
// Explicit specialization.
template <> void foo<int>(int a) {}// Explicit instantiation declaration.
extern template void foo<char*>(char* s);typedef char Char;
// Another (redundant) explicit inst. decl.
extern template void foo(Char* s);// Explicit instantiation definition.
template void foo(double);Quoting from Sema::SemaTemplate.cpp:
// FIXME: Create an ExplicitInstantiation node?
[...]
// FIXME: We may still want to build some representation of this
// explicit specialization.
[...]
// FIXME: Create some kind of ExplicitInstantiationDecl here.We would like to hear opinions about the following proposal for filling
in those FIXMEs. The main goal is to provide a better distinction
between the syntactic and semantic issues. As hinted in the comments
above, we should introduce a new Decl node whose purpose is to represent
all syntactic aspects of the explicit specialization/instantiation of
(members of) templates. Let us call this new class (better names are
welcome)ExplicitSpecOrInstDecl
In our opinion, this class should be derived directly from Decl (rather
than inheriting from more concrete classes), provide all and only the
syntactic info which is peculiar of explicit template
specializations/instantiations (i.e., source locations of the optional
"extern" keyword, of the "template" keyword and of the optional "<>"
brackets) and then contain an appropriate Decl node for a proper
representation of the other stuff. That is, the new node will be somehow
similar to a LinkageSpecDecl node (but it will not be a DeclContext).Note that even the declaration contained in the ExplicitSpecOrInstDecl
node will be mainly providing syntactic info: that is, for a construct
such asextern template void foo(Char* s);
we will have an ExplicitSpecOrInstDecl node
(representing "extern template")
containing a FunctionDecl node
(representing "void foo(Char* s);"
I agree that this is a good way to model explicit instantiations and specializations.
The actual, semantic instantiation of the function template foo for
template argument char* will be stored somewhere else (and will be
possibly be completely unaffected by this syntactic declaration).
We'll need to create a (re-)declaration of the function template specialization that contains the various parameters, template arguments, etc. as written in the explicit specialization or instantiation.
If the proposal above makes some sense, then we should also consider
whether or not it would be appropriate to extend it to the case of class
template specializations or instantiations (and even member classes of
class templates). We stress this point because currently for class
template a different approach is being used, whereby a class template
specialization is inheriting from CXXRecordDecl. This in our opinion is
a suboptimal design choice.
There is a difference here... FunctionDecl stores its template arguments and associated specialization information in members, while CXXRecordDecl has the ClassTemplateSpecializationDecl subclass to store this information. How is it suboptimal?
- Doug
What'is the reason to not follow a similar pattern to what is proposed
above for functions?
The ExplicitSpecOrInstDecl node refers two decls: one for syntactic form
and possibly another for instantiated automatically generated content.
Abramo Bagnara wrote:
Hello Enea,
Hello.
clang AST is missing nodes able to represent various kinds of instantiations and/or specializations of (member of class) templates, such as the following:
============================================
// Explicit specialization.
template <> void foo<int>(int a) {}// Explicit instantiation declaration.
extern template void foo<char*>(char* s);typedef char Char;
// Another (redundant) explicit inst. decl.
extern template void foo(Char* s);// Explicit instantiation definition.
template void foo(double);Quoting from Sema::SemaTemplate.cpp:
// FIXME: Create an ExplicitInstantiation node?
[...]
// FIXME: We may still want to build some representation of this
// explicit specialization.
[...]
// FIXME: Create some kind of ExplicitInstantiationDecl here.We would like to hear opinions about the following proposal for filling in those FIXMEs. The main goal is to provide a better distinction between the syntactic and semantic issues. As hinted in the comments above, we should introduce a new Decl node whose purpose is to represent all syntactic aspects of the explicit specialization/instantiation of (members of) templates. Let us call this new class (better names are welcome)
ExplicitSpecOrInstDecl
In our opinion, this class should be derived directly from Decl (rather than inheriting from more concrete classes), provide all and only the syntactic info which is peculiar of explicit template specializations/instantiations (i.e., source locations of the optional "extern" keyword, of the "template" keyword and of the optional "<>" brackets) and then contain an appropriate Decl node for a proper representation of the other stuff. That is, the new node will be somehow similar to a LinkageSpecDecl node (but it will not be a DeclContext).
Note that even the declaration contained in the ExplicitSpecOrInstDecl node will be mainly providing syntactic info: that is, for a construct such as
extern template void foo(Char* s);
we will have an ExplicitSpecOrInstDecl node
(representing "extern template")
containing a FunctionDecl node
(representing "void foo(Char* s);"I agree that this is a good way to model explicit instantiations and specializations.
The actual, semantic instantiation of the function template foo for template argument char* will be stored somewhere else (and will be possibly be completely unaffected by this syntactic declaration).
We'll need to create a (re-)declaration of the function template specialization that contains the various parameters, template arguments, etc. as written in the explicit specialization or instantiation.
If the proposal above makes some sense, then we should also consider whether or not it would be appropriate to extend it to the case of class template specializations or instantiations (and even member classes of class templates). We stress this point because currently for class template a different approach is being used, whereby a class template specialization is inheriting from CXXRecordDecl. This in our opinion is a suboptimal design choice.
There is a difference here... FunctionDecl stores its template arguments and associated specialization information in members, while CXXRecordDecl has the ClassTemplateSpecializationDecl subclass to store this information. How is it suboptimal?
What'is the reason to not follow a similar pattern to what is proposed
above for functions?
Having a uniform approach is one of the pros.
Anyway, when reasoning about the suboptimality of design, I was (implicitly) referring to the whole CXXRecordDecl inheritance hierarchy.
It may just be a matter of taste (no one here is pretending to separate what is "right" from what is "wrong"), but I find it strange to see a ClassTemplatePartialSpecializationDecl inheriting from ClassTemplateSpecializationDecl inheriting from CXXRecordDecl ... these do not look to be proper ISA relationships. Why should a partial specialization provide info about the "extern" keyword or the "<>" braces? Why should it have method getSpecializationKind() when all partial specialization are explicit?
To my eyes, a design based on containment rather than inheritance would probably be a little bit cleaner. Unless there are other reasons to prefer inheritance ...
Cheers,
Enea.
Well, "extern" doesn't make sense for explicit specializations or implicit instantiations, either, but I understand your point that the CXXRecordDecl hierarchy could be cleaned up. CXXRecordDecl, for example, should be eliminated, and its C++-specific methods migrated to RecordDecl. ClassTemplateSpecializationDecl could also be collapsed into RecordDecl, so long as we find a place to introduce the FoldingSetNode. There may even been
As for ClassTemplatePartialSpecializationDecl... it is somewhat odd, because it is neither a class nor a template of its own, but it acts like both.
- Doug