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, 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?
Thanks!
Paolo.
