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

[Richard Smith]

On Wed, Apr 25, 2012 at 3:54 PM, Chandler Carruth <chandlerc at google.com>wrote:

> 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.
>

Thanks, r155597.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120425/9d065514/attachment.html>