This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] PR c++/26256
- From: Jason Merrill <jason at redhat dot com>
- To: Fabien ChÃne <fabien dot chene at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 19 Sep 2011 20:02:25 -0400
- Subject: Re: [Patch] PR c++/26256
- References: <AANLkTikY4pcci892bD0M2MsbakFvrK4r15csPFSLT5nO@mail.gmail.com> <4C0EB10C.3050701@redhat.com> <AANLkTimONzSNNiUarwu1vU1AhiTUf2Ug_mKJE4Ya2LXj@mail.gmail.com> <4C1AD953.3020008@redhat.com> <AANLkTikL5DwqQd2egQzgwUngEc+NtYax-jdpaQrp0p+-@mail.gmail.com> <AANLkTinuzT8Umh0NF3Nbx2r70TYqeK5UP54qnRuHYcBq@mail.gmail.com> <4C6E0571.3070802@redhat.com> <AANLkTi=38qQdh-BzrFTJ5uHDH_F+sctb+iJAinKuMC3k@mail.gmail.com> <AANLkTi=RB6sn_ic5Pb30yxkjn0VMME5y8ZK9k5VMGRDK@mail.gmail.com> <AANLkTin5FvEzTYUg+W5bRzk462LaJ4hpk3s+yxZzF_RY@mail.gmail.com> <AANLkTinjj2vPrOkbE0qK1ht7YwxwQmXFhPnGPSvVQNgw@mail.gmail.com> <4D1279FD.6010706@redhat.com> <AANLkTinkB+iwTHZXngtOa88rgBScyrMK2R9p7H5yCbrj@mail.gmail.com> <4D7297F5.2000708@redhat.com> <AANLkTimbWH16eyQGhxAMiCO+CnVQdRAi4V0U7=hAfv_6@mail.gmail.com> <BANLkTikiHetQQph8QGGU+YpodC4YK61-dg@mail.gmail.com> <4E020BE2.7080207@redhat.com> <CAFH4-di=DitSxtnhTM4cv_vgNchvgA2v42q=7xdxqxusKcEDbw@mail.gmail.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. */
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.
+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.
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?