On Aug 30, 2010, at 2:27 PM, Benoit Belley wrote:
> Thanks for taking the time to review my changes. The following patch should
> address all of your concerns. I have clarified that I want to traverse all of
> the template instantiations (not just the explicit ones).
>
> /// This visitor always recurses in the declarator of explicit
> /// template instantiations, such as for example "template class
> /// set<int>'. But by default, it will not recurse in the
> /// instantiations (implicit or explicit) of the template (function or
> /// class) themselves since the instatiated AST isn't written in the
> /// source code anywhere. This behavior can be changed by overriding
> /// shouldVisitTemplateInstantiations() in the derived class to return
> /// true.
>
> Unfortunately, while testing my changes, I have come across an issue and I
> don’t know what the correct solution is. The following code snippet (inspired
> from the Intel TBB header files) demonstrates the issue:
>
>
> —————————————————
> // This is fine.
> class A
> {
> friend class A;
> }
>
> // This class template definiton is also fine...
> template<typename Container>
> class vector_iterator
> {
> template <typename C> friend class vector_iterator;
> };
>
> // ... until it gets instantiated.
> vector_iterator<int> it_int;
> --------------------------------
>
> It will throw the RecursiveASTVisitor in an infinite loop when
> shouldVisitTemplateInstantiations() == true. The attached file tracing.txt
> contains a trace of the visitor in action and points out to cause of the
> problem:
Probably you should only visit the instantiations for the template definition.
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
