2011/9/21 Jason Merrill <ja...@redhat.com>:
> On 09/21/2011 01:59 PM, Fabien Chêne wrote:
>>>>
>>>> if (!DECL_DEPENDENT_P (field))
>>>> - continue;
>>>> + {
>>>> + tree using_decl = USING_DECL_DECLS (field);
>>>> + if ((TREE_CODE (using_decl) == FIELD_DECL
>>>> + || TREE_CODE (using_decl) == TYPE_DECL)
>>>> +&& DECL_NAME (using_decl) == name)
>>>> + return using_decl;
>>>> + continue;
>>>> + }
>>>
>>> This section needs a comment. Why do we look through USING_DECL for
>>> these
>>> two kinds of member but not others?
>>
>> I was looking explicitely for a FIELD_DECL or a TYPE_DECL because it
>> was crashing if I didn't. In fact, it was simply that DECL_NAME needs
>> at least tree_minimal, which OVERLOAD doesn't have. Is there a way to
>> properly check that DECL_NAME will succeed ?
>
> You could check DECL_P first, but don't we want to return the OVERLOAD here,
> too? You can use get_first_fn to get a FUNCTION_DECL out of anything that
> satisfies is_overloaded_fn.
I would have thought that we want to do something with OVERLOAD here,
in order to get rid of PR c++/30195 and c++/25994 (removing a wrong
diagnostic additionaly)... But those PRs are already fixed by this
patch without doing anything with OVERLOAD. Consequently, I don't
really know why it would be needed, but I can certainly do it if you
prefer. Have you got an example in mind where it would be needed ?
--
Fabien
