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"?
+ 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.
/* 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.
Jason
