[cfe-commits] RecursiveASTVisitor: visit all implicit template specializations with the primary template

Chandler Carruth chandlerc at google.com
Wed Apr 25 15:54:21 PDT 2012


On Wed, Apr 25, 2012 at 3:26 PM, John McCall <rjmccall at apple.com> wrote:

> On Apr 25, 2012, at 2:57 PM, Richard Smith wrote:
> > Our current strategy is that RecursiveASTVisitor attempts to visit
> template specializations as part of visiting the template from which the
> specializations are instantiated. This goes wrong for a partial
> specialization of a member template of a class template:
> >
> >   template<typename T> struct A {
> >     template<typename U> struct B;
> >   };
> >
> >   template<typename T> template<typename U> struct A<T>::B<U*> {};
> >
> > Here, it's not trivial to find the specializations which are
> instantiated from the partial specialization, and the RecursiveASTVisitor
> fails to find them.
> >
> > A somewhat-related problem is that we do not visit template
> specializations where we have instantiated the declaration but not the
> definition. In such cases, we do not know (and, from the
> RecursiveASTVisitor, cannot reasonably compute) which primary template or
> partial specialization an instantiated declaration should be associated
> with, so the existing strategy cannot be applied there.
> >
> > I propose that we fix both of these issues by visiting all implicit
> instantiations of a template (including cases where we have not
> instantiated a definition) when we visit the primary template; a patch
> implementing this is attached.
> >
> > This conflicts with the chosen direction from when this functionality
> was added [1], so I'd like to hear any concerns with this direction.
>
> I have no particular problem with this, but I have never written a
> RecursiveASTVisitor that wanted to visit instantiations.


When we want to visit instantiations (and I agree, we often don't hence the
bit to keep it disabled by default), we should visit all of them, and the
most idomatic way possible. So, LGTM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120425/ffe0fd11/attachment.html>


More information about the cfe-commits mailing list