[cfe-commits] [Patch][Review request] RecursiveASTVisitor can now traverse template specializations

[Benoit Belley]

Hi John,

I think that I’ll need a bit more explanation here. The infinite recursion occurs while traversing the instantiations of the class template definition and I do want to traverse these instantiations. That’s the whole point of my proposed change.

By the way, here’s one more bit of information.  The problem does not occur when the template is explicitly instantiated:

-----------------------------------------------------------------------------
template<typename Container>
class vector_iterator
{
    template <typename C> friend class vector_iterator;
};

vector_iterator<int> it_int;

template class vector_iterator<int>;
-----------------------------------------------------------------------------
....
  Visiting Decl ClassTemplateSpecialization @0x105046ec0 (vector_iterator) {
    getSpecializationKind() = 4
    Visiting Decl CXXRecord @0x105047190 (vector_iterator<int>::vector_iterator) {
      "***Implicit declaration ignored***"
    }
    Visiting Decl Friend @0x105047350 () {
      Visiting Decl ClassTemplate @0x105047310 (vector_iterator) {
        Visiting Decl CXXRecord @0x105047280 (vector_iterator) {
        }
        Visiting Decl TemplateTypeParm @0x105047220 (vector_iterator<int>::<anonymous>) {
        }
      }
    }
  }
}
-----------------------------------------------------------------------------

You see how the FriendDecl at 0x105047350 refers to a ClassTemplate instead of the ClassTemplateSpecialization at 0x105046ec0.

Which leads me to wonder even more whether the AST produced when scanning the code snippet of my previous example is valid or not ?

- Shouldn’t the AST form a DAG ?
- Are cycles really allowed in the AST ?
- Why would a cycle be necessary when using implicit instantiation and not for explicit instantiation ?
- Etc...

I’ll try digging further because I’ll really need this to work.

Benoit

Le 2010-08-30 à 17:30, John McCall a écrit :

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.



Benoit Belley
Sr Principal Developer
M&E-Product Development Group

Autodesk Canada Inc.
10 Rue Duke
Montreal, Quebec  H3C 2L7
Canada

Direct 514 954-7154



[cid:image002.gif at 01CAF376.C0A99470]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 651 bytes
Desc: image002.gif
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100830/b3ad72ea/attachment.gif>