Hi,
Sorry for the looong delay,
2010/12/22 Jason Merrill <ja...@redhat.com>:
> On 12/20/2010 07:02 AM, Fabien Chêne wrote:
>>
>> + {
>> + 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;
>> + }
>
> I think if a USING_DECL designates a function, it shouldn't be in
> TYPE_FIELDS. And if we do need any code for handling USING_DECL here, don't
> we need it for the sorted case above as well?
>
>> - if (TREE_CODE (decl) == TYPE_DECL && DECL_ARTIFICIAL (decl))
>> + if (TREE_CODE (decl) == TYPE_DECL && DECL_ARTIFICIAL (decl)
>> + && (TREE_CODE (bval) != USING_DECL
>> + || (!DECL_DEPENDENT_P (bval)
>> + && (TREE_CODE (USING_DECL_DECLS (bval)) != TYPE_DECL))))
>
> Why is this change needed? Why is the unconditional setting of
> binding->type when we see a nested class no longer appropriate?
>
> It seems to me that instead of special-casing using-declarations in
> supplement_binding, we want the code that currently checks the tree code of
> decl and bval to look through USING_DECLs. Likewise in
> push_class_level_binding.
>
> How are using-declarations combined with normal declarations?
Hmm, I've implemented what you were suggesting, and I don't understand
the following check in supplement_binding:
else if (TREE_CODE (bval) == TYPE_DECL && DECL_ARTIFICIAL (bval))
{
/* The old binding was a type name. It was placed in
VALUE field because it was thought, at the point it was
declared, to be the only entity with such a name. Move the
type name into the type slot; it is now hidden by the new
binding. */
binding->type = bval;
binding->value = decl;
binding->value_is_inherited = false;
}
Why is it usefull ? It prevents the following illegal code from being rejected:
struct A
{
struct type {};
typedef int type;
};
Hence, the same now happens with using declarations.
--
Fabien
