Re: [PR c++/84962] ICE with anon-struct member

[Jason Merrill <jason at redhat dot com>]

On Tue, Mar 20, 2018 at 9:55 AM, Nathan Sidwell <nathan@acm.org> wrote:
> This fixes the 84962 ICE, which is where we name a member function of an
> anon-struct in the width specifier of a bitfield.  The problem is that when
> permissive we allow some of this strangeness. Prior to my lookup changes, we
> only added TYPE_FIELDS and we still do that.  Trouble is that now contains
> member functions, and badness happens.  The fix is to add the member_vec
> members, if that exists, which takes care of overloaded.
>
> Due to history, we don't check some of the anon-struct restrictions until
> the outer struct is complete.  That's partly historical and partly because
> we don't tell the struct parser the difference between
>
> struct X {
>    struct { ... };  // anon-struct
>    typedef struct { ... } name; // not an anon-struct

Right, because we can't tell until after the struct:

     struct { ... } member; // also not an anon-struct

> However, all this stuff is an extension:
> 1) we permit anon-struct, not just anon-union
> 2) we permit things other than non-static-data members

> Maybe we could deprecate #2 at least?  I'm not sure what its use case might
> be.

Fine with me.  I know #1 was deliberate, but I haven't been aware of #2 before.

Jason