Re: [RFH / Patch] PR 51222

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

Hi,

On 05/01/2012 08:02 PM, Jason Merrill wrote:
> On 05/01/2012 08:00 AM, Paolo Carlini wrote:
> > > I think either approach would be fine; I lean toward the first, but
> > > changing the name and adding a flag for clarity. Changing the walking
> > > behavior based on fn being null is too subtle.
> > Agreed. The below is what I booted and tested on x86_64-linux.
>
> > +   If ANY_P is true, return 1 if any, 0 otherwise.
>
> This isn't really what the parameter means; it means also look into 
> the types of declarations used in the expression.  So perhaps call it 
> "check_types"?
Ok.
> > +   If ANY_P is false, for each the iteration calls FN with the 
> > parameter
> > +   and the DATA.
>
> This doesn't actually depend on ANY_P, it depends on whether or not FN 
> is null.
Ok.
> >       /* If there's no type, then this thing must be some expression
> >          involving template parameters.  */
> >       if (!fn && !TREE_TYPE (t))
> >         return error_mark_node;
>
> Hmm, this preexisting code seems to assume that any type-dependent 
> expression must include a direct use of a template parameter, but it 
> might just have a declaration with dependent type.  We should also 
> test any_p/check_types, and this should apply to all expressions, not 
> just these.
>
> >     case MODOP_EXPR:
> >     case CAST_EXPR:
> >     case IMPLICIT_CONV_EXPR:
> >     case REINTERPRET_CAST_EXPR:
> >     case CONST_CAST_EXPR:
> >     case STATIC_CAST_EXPR:
> >     case DYNAMIC_CAST_EXPR:
> >     case ARROW_EXPR:
> >     case DOTSTAR_EXPR:
> >     case TYPEID_EXPR:
> >     case PSEUDO_DTOR_EXPR:
> >       if (!fn)
> >         return error_mark_node;
> >       break;
>
> This pre-existing code seems like it will do the wrong thing; these 
> codes don't necessarily imply a dependent expression.  We can drop 
> these cases, too.
I'm not 100% sure to understand the last two comments. I'm removing 
completely the latter cases and changing the former like the below. Note 
that the way I handle fn in walk_template_parms implies that when 
check_types is true then pfd->fn is always NULL in  walk_template_parms_r.

The attached passes testing.

Paolo.

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

Attachment: patch_51222_5
Description: Text document