https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124610
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The ICE is because while parsing the class bases, current_class_type is already
set to the derived class (so B in the first testcase in #c1). And in that case
build_enumerator does:
if (context && context == current_class_type && !SCOPED_ENUM_P (enumtype))
{
/* In something like `struct S { enum E { i = 7 }; };' we put `i'
on the TYPE_FIELDS list for `S'. (That's so that you can say
things like `S::i' later.) */
/* The enumerator may be getting declared outside of its enclosing
class, like so:
class S { public: enum E : int; }; enum S::E : int { i = 7; };
For which case we need to make sure that the access of `S::i'
matches the access of `S::E'. */
auto cas = make_temp_override (current_access_specifier);
set_current_access_from_decl (TYPE_NAME (enumtype));
finish_member_declaration (decl);
}
else
pushdecl (decl);
but finish_member_declaration ICEs because
/* Don't add decls after definition. */
gcc_assert (TYPE_BEING_DEFINED (current_class_type)
/* We can add lambda types when late parsing default
arguments. */
|| LAMBDA_TYPE_P (TREE_TYPE (decl)));
Here it actually isn't after definition but before definition, we haven't set
TYPE_BEING_DEFINED yet.
Guess the question is if we need to support any attribute on the class base
declarations which need to define new types and if yes, where such type
definitions should go (whether on the scope surrounding the derived class or
inside of the derived class).
Without reflection I think we ignore all attributes in there (and the question
is if except for alignas which is not valid there we can arrange some type
definitions there), with reflection the question is again if valid code can
define new types in there.
If not, guess we could just forbid definition of new types in those attributes.
