https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98533
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
struct S {
template <typename> void foo (int = [] {}) const;
};
struct T {
static void bar (const S &);
};
The earlier finish_member_declaration calls are followed by finish_struct ->
finish_struct_1 -> finish_struct_bits -> fixup_type_variants which updates the
variants
(there is const S next to the S main variant).
But later on there is
#0 finish_member_declaration (decl=<template_decl 0x7fffea13ae58 ._anon_0>) at
../../gcc/cp/semantics.cc:4294
#1 0x00000000006bad53 in maybe_process_template_type_declaration
(type=<record_type 0x7fffea2e9738 ._anon_0>, is_friend=0, b=0x7fffea1378b8) at
../../gcc/cp/name-lookup.cc:8400
#2 0x00000000006bb132 in pushtag (name=<identifier_node 0x7fffea301640
._anon_0>, type=<record_type 0x7fffea2e9738 ._anon_0>,
how=TAG_how::CURRENT_ONLY)
at ../../gcc/cp/name-lookup.cc:8500
#3 0x0000000000575fdd in xref_tag (tag_code=record_type, name=<identifier_node
0x7fffea301640 ._anon_0>, how=TAG_how::CURRENT_ONLY, template_header_p=false)
at ../../gcc/cp/decl.cc:17213
#4 0x00000000005e9271 in begin_lambda_type (lambda=<lambda_expr
0x7fffea15e0a0>) at ../../gcc/cp/lambda.cc:138
#5 0x00000000006df1b2 in cp_parser_lambda_expression (parser=0x7fffea2e9a80)
at ../../gcc/cp/parser.cc:11739
#6 0x00000000006d104b in cp_parser_primary_expression (parser=0x7fffea2e9a80,
address_p=false, cast_p=false, template_arg_p=false, decltype_p=false,
idk=0x7fffffffbf7c)
at ../../gcc/cp/parser.cc:6229
#7 0x00000000006d6516 in cp_parser_postfix_expression (parser=0x7fffea2e9a80,
address_p=false, cast_p=false, member_access_only_p=false, decltype_p=false,
pidk_return=0x0)
at ../../gcc/cp/parser.cc:8238
#8 0x00000000006dad9e in cp_parser_unary_expression (parser=0x7fffea2e9a80,
pidk=0x0, address_p=false, cast_p=false, decltype_p=false) at
../../gcc/cp/parser.cc:9733
#9 0x00000000006dc581 in cp_parser_cast_expression (parser=0x7fffea2e9a80,
address_p=false, cast_p=false, decltype_p=false, pidk=0x0) at
../../gcc/cp/parser.cc:10648
#10 0x00000000006dc684 in cp_parser_binary_expression (parser=0x7fffea2e9a80,
cast_p=false, no_toplevel_fold_p=false, decltype_p=false,
prec=PREC_NOT_OPERATOR, pidk=0x0)
at ../../gcc/cp/parser.cc:10751
#11 0x00000000006dd832 in cp_parser_assignment_expression
(parser=0x7fffea2e9a80, pidk=0x0, cast_p=false, decltype_p=false) at
../../gcc/cp/parser.cc:11096
#12 0x00000000006de26b in cp_parser_constant_expression (parser=0x7fffea2e9a80,
allow_non_constant_p=2, non_constant_p=0x0, strict_p=false) at
../../gcc/cp/parser.cc:11402
#13 0x00000000007007ed in cp_parser_initializer_clause (parser=0x7fffea2e9a80,
non_constant_p=0x0) at ../../gcc/cp/parser.cc:26844
#14 0x00000000007005f5 in cp_parser_initializer (parser=0x7fffea2e9a80,
is_direct_init=0x0, non_constant_p=0x0, subexpression_p=false) at
../../gcc/cp/parser.cc:26783
#15 0x000000000071267f in cp_parser_late_parse_one_default_arg
(parser=0x7fffea2e9a80, decl=<parm_decl 0x7fffea13ac38>,
default_arg=<deferred_parse 0x7fffea2fc5b8>,
parmtype=<integer_type 0x7fffea1525e8 int>) at ../../gcc/cp/parser.cc:34576
#16 0x0000000000712a75 in cp_parser_late_parsing_default_args
(parser=0x7fffea2e9a80, fn=<function_decl 0x7fffea2ecb00 foo>) at
../../gcc/cp/parser.cc:34689
which pushes another TYPE_FIELDS and nothing propagates that to the variants
afterwards.
I guess the most important question is if the lambda ._anon_0 from the default
argument and its associated TEMPLATE_DECL should be pushed into the TYPE_FIELDS
of the containing class at all. If yes, there should be some further
fixup_type_variants to sync that up after processing all the late default
arguments. If not, what should prevent that and where should that lambda go
(if anywhere)?
Jason, any ideas?
