On Tue, May 8, 2018 at 1:46 PM, Paolo Carlini <paolo.carl...@oracle.com> wrote: > Hi, > > On 08/05/2018 19:15, Jason Merrill wrote: >> >> On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini <paolo.carl...@oracle.com> >> wrote: >>> >>> Hi, >>> >>> in this error-recovery regression, after sensible diagnostic about "two >>> or >>> more data types in declaration..." we get confused, we issue a cryptic - >>> but useful hint to somebody working on the present bug ;) - "template >>> definition of non-template" error and we finally crash. I think the issue >>> here is that we want to use abort_fully_implicit_template as part of the >>> error recovery done by cp_parser_parameter_declaration_list, when the >>> loop >>> is exited early after a cp_parser_parameter_declaration internally called >>> synthesize_implicit_template_parm. Indeed, if we do that we get the same >>> error recovery behavior we get for the same testcase modified to not use >>> an >>> auto parameter (likewise for related testcases): >>> >>> struct a { >>> void b() {} >>> void c(auto = [] { >>> if (a a(int int){}) >>> ; >>> }) {} >>> }; >> >> Hmm, the erroneous declaration is within the lambda body, so messing >> with whether c is a template seems wrong. > > I'm sorry, I don't follow: why you think the issue has to do with c? The > issue happens while we are parsing: > > a a(int auto) > > in the original testcase, in particular the parameters. We set > parser->fully_implicit_function_template_p in > synthesize_implicit_template_parm, which in turn is called by > cp_parser_simple_type_specifier when it sees the auto. As I said, we don't > have the bug for the snippet you quote above, which is identical to that > attached in the bug but for the auto in the declaration of a: > > struct a { > void b() {} > void c(void (*) () = [] { > if (a a(int auto){}) > ; > }) {} > };
Ah, I was assuming the quoted testcase was the one in the PR. The patch is OK. Jason