[Bug preprocessor/105732] [9/10/11/12/13 Regression] internal compiler error: unspellable token PADDING

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With a slightly modified testcase:
#define m1(p1, p2, p3) p3
#define m2(p1, ...) 1 __VA_OPT__()
#define M(...) m1(1, 2, m2)
#if M(,)(,)
#endif
it started to ICE already with r8-6791-g60887f8c2df851 aka PR83708 fix.

The r12-6155-g5545d1edcbdb17 change just turns that into the same tokens as
before, while previously it wasn't.  As __VA_OPT__() or __VA_OPT__(foo) in both
cases expands to nothing, 1##nothing is still 1 and the avoid_paste token is
added afterwards to make sure token after __VA_OPT__() isn't emitted right
after it without whitespace.

It isn't immediately clear to me what should be eating the padding token so
that
cpp_parse_expr doesn't see it.

Or is this a bug in cpp_parse_expr?
I mean, other callers of cpp_get_token_with_location like e.g. in
c_lex_with_flags handle CPP_PADDING by calling cpp_get_token_with_location
again.
Similarly scan_translation_unit when doing -E, token_streamer::stream just
remembers there was padding and goes on (and takes that into account whether
whitespace should be emitted or not).