Hi,
On 10/01/2018 17:58, Jason Merrill wrote:
On Wed, Jan 10, 2018 at 11:33 AM, Paolo Carlini
<paolo.carl...@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.carl...@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.
Ok. I'm going to investigate that a bit more - the obvious idea would be
limiting somehow the approach to when we are *not* parsing tentatively -
otherwise I'll see if we can handle elegantly enough those
error_mark_nodes. I committed the other straightforward change which you
approved, thanks about that.
Paolo.
