This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ Patch/RFC] PR 84348 ("[7/8 Regression] ICE with invalid friend declaration")


OK.

On Fri, Feb 16, 2018 at 5:30 PM, Paolo Carlini <paolo.carlini@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.
>
> ////////////////////
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]