Hi Doug, Jason suggested that I write to you about this. There seems
to be some confusion in the code in cp/pt.c between enum
unification_kind_t (DEDUCE_xxx) and a bitmask of UNIFY_ALLOW_xxx
values. The parameters are named "strict" for all functions, but in
some cases they are unification_kind_t and in some cases they are int.
The collision happens in unify_pack_expansion. unify calls
unify_pack_expansion with a bitmask. type_unification_real calls
unify_pack_expansion with a unification_kind_t. Within
unify_pack_expansion, I see this:
int arg_strict = strict;
...
if (call_args_p)
{
...
switch (strict)
{
case DEDUCE_CALL:
sub_strict = (UNIFY_ALLOW_OUTER_LEVEL
| UNIFY_ALLOW_MORE_CV_QUAL
| UNIFY_ALLOW_DERIVED);
...
}
...
arg_strict = sub_strict;
...
}
...
if (unify (tparms, targs, parm, arg, arg_strict))
return 1;
In other words, in the switch statement the parameter strict is
treated as a unification_kind_t. arg_strict is set to either a
unification_kind_t (call_args_p false) or a UNIFY_ALLOW bitmask
(call_args_p true). Either way, it is passed on to unify.
It's remotely possible that this code is working as intended. But it
sure looks wrong.
Ian
