Re: [RFH / Patch] PR 51222

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi again,
> On 04/29/2012 11:42 AM, Paolo Carlini wrote:
> > > This might just be a matter of calling for_each_template_parm and
> > > returning 1 if we see any template parameter.
> > Good. Today I quickly tried something along these lines (see 'p'
> > attachment) and got some fails:
>
> Ah, well.  I guess for_each_template_parm doesn't look at the types of 
> declarations.
Just a few moments ago I noticed something interesting: if a NULL FN is 
passed to for_each_template_parm, it assumes a function which always 
returns 1, what we want when just searching for the first occurrence. 
Now, in practice, *no* front-code calls it like this! Thus, if we want, 
it's safe to tweak / extend for_each_template_parm_r for our purposes 
when !fn

And indeed, the attached passes the testsuite with no regressions ;)

I also want to remark that there is this kind of comment:

    case INDIRECT_REF:
    case COMPONENT_REF:
      /* If there's no type, then this thing must be some expression
     involving template parameters.  */
      if (!fn && !TREE_TYPE (t))
    return error_mark_node;
+      else if (!fn && for_each_template_parm (TREE_TYPE (t), fn,
+                          data, pfd->visited,
+                          pfd->include_nondeduced_p))
+    return error_mark_node;

which, how can I say, appears to "support" the idea of tweaking / 
extending the code in the direction we like.

Thus, my question would be: is something like the below in the right 
direction? The alternate possibility I can see, would be basically 
redoing a slightly slimmed version of for_each_template_parm specialized 
for our needs (a few less conditionals)

Thanks!

Paolo.

////////////////////////////

Attachment: patch_51222_3
Description: Text document