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. > 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
