This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFH / Patch] PR 51222

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:
      /* 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)




Attachment: patch_51222_3
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]