Hi, 2011/9/20 Jason Merrill <ja...@redhat.com>: > On 09/17/2011 09:44 AM, Fabien Chêne wrote: >> >> I tried various things without success, and I ended up hacking >> supplement_binding_1 to handle those ENUMERAL_TYPEs. >> I am all ear for another solution ... > > Your solution seems reasonable to me, but it needs a comment, along the > lines of > > /* We allow pushing an enum multiple times in a class template in order to > handle late matching of underlying type on an opaque-enum-declaration > followed by an enum-specifier. */
Done.
> And I guess limit it to dependent class scope. Incidentally, repeating
> opaque-enum-declarations at class scope is invalid under 9.2/1:
>
> --
> A member shall not be declared twice in the member-specification, except
> that a nested class or member class template can be declared and then later
> defined, and except that an enumeration can be introduced with an
> opaque-enum-declaration and later redeclared with an enum-specifier.
> --
>
> So
>
> struct A
> {
> enum E: int;
> enum E: int { e1 };
> };
>
> is OK, but
>
> struct B
> {
> enum E: int;
> enum E: int;
> };
>
> is not.
Hence, I think there is currently a bug here. Moreover, some tests are
checking the above example (forw_enum{3,4}.C at least). However, I
think that fixing this bug is beyond the scope of this patch. I'll
fill in a bug for this issue.
>> +static tree
>> +strip_using_decl (tree decl)
>
> Needs a comment. Also, this function has a loop in it, but various other
> places in the patch that look through USING_DECLs don't loop.
Done.
>> 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 ?
Attached an updated patch, regtested on x86_64-unknown-linux-gnu.
--
Fabien
pr26256.patch
Description: Binary data
