OK.
On Fri, Feb 16, 2018 at 5:30 PM, Paolo Carlini <paolo.carl...@oracle.com> wrote: > Hi, > > here we ICE during error recovery when, after emitting a correct error from > grokdeclarator, we go on, we only clear friendp, and grokfield proceeds to > call cp_finish_decl where 'gcc_assert (CLASS_PLACEHOLDER_TEMPLATE > (auto_node));' triggers. We could imagine solving the problem in various > ways... If we want to do something as early as possible, in grokdeclarator, > over the years in turn we handled different cases in different ways related > to the error recovery effects, mostly. A straightforward solution, which I'm > finishing testing, would be just bailing-out after the error, alternately we > could also imagine something relatively sophisticated like going on, but > also setting type = error_mark_node conditional to type_uses_auto (auto) > thus mimicking the error recovery strategy we use above for a non-friend > ill-formed variant. Just unconditionally setting type = error_mark_node > doesn't seem morally correct to me - even if probably it would also pass the > testsuite - because what we are actually diagnosing to the user, in fact the > first problem in such snippet in parsing order, doesn't have to do with the > type per se, but with friend - the diagnostic for 'friend int foo' is the > same. As usual I'm on x86_64-linux. > > Thanks, Paolo. > > //////////////////// >
