Re: PR c++/30195

[Fabien Chêne <fabien dot chene at gmail dot com>]

Hi,

2011/10/12 Jason Merrill <jason@redhat.com>:
>>> Copying the decl is unlikely to do what we want, I think. ?Does putting
>>> the
>>> target decl directly into the method vec work?
>>
>> Unfortunately not, it ends up with the same error: undefined
>> reference.
>
> Hunh, that's surprising.
>
>> Furthermore, I don't think it is the right approach since
>> the access may be different between the member function and the using
>> declaration... Never mind.
>
> I would expect the existing access declaration code to deal with that,
> though I could be wrong.

After looking into it a bit more, I now see things differently. The
target_decl is in fact put into the CLASSTYPE_METHOD_VEC at
instantiation time, via handle_using_decl, with the correct access.
The problem is that while parsing the template (before instantiating),
it is not yet there and an error is immediately raised. I only see
three solutions:
1) perform an additional lookup for using declarations that designate
functions in lookup_fnfields_slot to find something even if the
CLASSTYPE_METOD_VEC is empty (what I implemented in the previous
patch)
2) inhibate the lookup error at some point.
3) put the decl into the CLASSTYPE_METHOD_VEC before instantiation

Honnestly, I don't know if 2) is realistic, and how to implement it as well ...
3) seems complicated: in finish_member_declaration, we must put away
the decl into TYPE_FIELDS or TYPE_METHODS, but we would like to put
the target_decl into TYPE_METHODS (and call add_method), and at the
same time put its  using decl into TYPE_FIELDS... I don't know if it
can theoretically work, but having try it, I think it would need many
adjustements.

What do you make of it ?

> There don't seem to be any tests for a class that both uses and defines
> functions with the same name to verify that both functions can be called; I
> suspect that doesn't work yet with this patch. ?If we can't put the used
> functions directly into CLASSTYPE_METHOD_VEC, we need to combine them with
> functions from there at lookup time.

Since the using decl is actually put into the CLASSTYPE_METHOD_VEC at
instantiation time, I think we don't have to worry about it.

>> + ? ? ? ? ? if (TREE_CODE (target_field) == FUNCTION_DECL
>> + ? ? ? ? ? ? ? && DECL_NAME (OVL_CURRENT (target_field)) == name)
>
> Checking for FUNCTION_DECL won't work if the target is overloaded.

Will be fixed.

[...]
>>Does the attached testcase checked  what you mention ?
>Yes, that's what I had in mind.

This testcase passes.

-- 
Fabien