On Mon, Jan 31, 2022 at 05:12:23PM -0500, Jason Merrill wrote:
> > --- libcpp/macro.cc.jj 2022-01-18 11:59:00.277972128 +0100
> > +++ libcpp/macro.cc 2022-01-31 15:44:49.208847524 +0100
> > @@ -1374,7 +1374,9 @@ funlike_invocation_p (cpp_reader *pfile,
> > if (token->type != CPP_PADDING)
> > break;
> > if (padding == NULL
> > - || (!(padding->flags & PREV_WHITE) && token->val.source == NULL))
> > + || padding->val.source == NULL
> > + || (!(padding->val.source->flags & PREV_WHITE)
> > + && token->val.source == NULL))
>
> What if padding->val.source == NULL and padding->flags & PREV_WHITE? Have
> you tried asserting that's not possible?
I haven't, but will do so now.
That said, I think at least for the shared avoid_paste token one should
better not change any flags on it.
And, at least the stringify_arg and c-ppoutput.cc (token_streamer::stream)
code doesn't care at all about PREV_WHITE flags on CPP_PADDING tokens, it
only cares about PREV_WHITE flags on its val.source.
The only other spot in c-ppoutput.cc that checks PREV_WHITE is cb_include
where the tokens must be CPP_COMMENT, glue_header_name after checking
PREV_WHITE on token->flags calls cpp_spell_token which for CPP_PADDING
errors out, etc.
More importantly, the setting of PREV_WHITE bit (flags |= PREV_WHITE etc.)
I see only in cpp_lex_direct which shouldn't produce CPP_PADDING tokens,
then paste_tokens copies it from old lhs to the pasted token, but the old
lhs goes through cpp_spell_token, so can't be CPP_PADDING unless an error
is diagnosed, create_iso_definition can copy it from CPP_HASH token
to CPP_MACRO_ARG or CPP_NAME, and that's it.
Jakub
