This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 78344 ("ICE on invalid c++ code (tree check: expected tree_list, have error_mark in cp_check_const_attributes, at cp/decl2.c:1347")
- From: Jason Merrill <jason at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Nathan Sidwell <nathan at acm dot org>
- Date: Wed, 10 Jan 2018 11:58:40 -0500
- Subject: Re: [C++ Patch] PR 78344 ("ICE on invalid c++ code (tree check: expected tree_list, have error_mark in cp_check_const_attributes, at cp/decl2.c:1347")
- Authentication-results: sourceware.org; auth=none
- References: <ba379e6d-a98c-c4a5-0de7-8f7333ff1458@oracle.com> <CADzB+2nDhjXh=pGSzyzLjyqRHTZ6KbUXDmVg=SjaCrJb2Taduw@mail.gmail.com> <39b5d3d5-58a3-1737-150d-60222dc3cb59@oracle.com>
On Wed, Jan 10, 2018 at 11:33 AM, Paolo Carlini
<paolo.carlini@oracle.com> wrote:
> Hi,
>
> On 10/01/2018 16:32, Jason Merrill wrote:
>>
>> On Fri, Dec 22, 2017 at 7:34 PM, Paolo Carlini <paolo.carlini@oracle.com>
>> wrote:
>>>
>>> in this error recovery issue cp_check_const_attributes and more generally
>>> cplus_decl_attributes have lots of troubles handling the error_mark_node
>>> returned by cp_parser_std_attribute_spec_seq, as called by
>>> cp_parser_direct_declarator. I fiddled quite a bit with these parsing
>>> facilities to eventually notice that boldly changing
>>> cp_parser_std_attribute_spec_seq to return NULL_TREE instead of
>>> error_mark_node when cp_parser_std_attribute_spec returns error_mark_node
>>> in
>>> the loop cures the bug at issue as a special case.
>>
>> Hmm, I'm skeptical. In general, we want to use error_mark_node to
>> distinguish between something not being there and being there but
>> wrong.
>
> I see what you mean. But consider that we already emitted diagnostic anyway,
I'm not sure we can rely on that; cp_parser_error doesn't emit
anything when parsing tentatively.
> and, important detail, isn't that we are dropping some correct attributes,
> we are dropping all of them anyway with error_mark_node or NULL_TREE the
> same way. It's just that with NULL_TREE we are behaving during error
> recovery as if the attributes weren't there in the first place. I'm not sure
> if this was 100% clear... Would you like to have some additional details?
It's clear, I'm just not convinced it's what we want.
Jason