mirror of
https://gcc.gnu.org/git/gcc.git
synced 2024-11-25 03:44:04 +08:00
58a40e76eb
The first part of the following testcase (m1-m3 macros and its use) regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows, the problem isn't new, we can emit a CPP_PADDING token to avoid it from being adjacent to whatever comes after the __VA_OPT__ (in this case there is nothing afterwards, true). In most cases these CPP_PADDING tokens don't matter, all other callers of cpp_get_token_with_location either ignore CPP_PADDING tokens completely (e.g. c_lex_with_flags) or they just remember them and take them into account when printing stuff whether there should be added whitespace or not (scan_translation_unit + token_streamer::stream). So, I think we should just ignore CPP_PADDING tokens the same way in _cpp_parse_expr. 2022-05-27 Jakub Jelinek <jakub@redhat.com> PR preprocessor/105732 * expr.cc (_cpp_parse_expr): Handle CPP_PADDING by just another token. * c-c++-common/cpp/va-opt-10.c: New test. |
||
|---|---|---|
| .. | ||
| include | ||
| po | ||
| aclocal.m4 | ||
| ChangeLog | ||
| ChangeLog.jit | ||
| charset.cc | ||
| config.in | ||
| configure | ||
| configure.ac | ||
| directives.cc | ||
| errors.cc | ||
| expr.cc | ||
| files.cc | ||
| generated_cpp_wcwidth.h | ||
| identifiers.cc | ||
| init.cc | ||
| internal.h | ||
| lex.cc | ||
| line-map.cc | ||
| location-example.txt | ||
| macro.cc | ||
| Makefile.in | ||
| makeucnid.cc | ||
| mkdeps.cc | ||
| pch.cc | ||
| symtab.cc | ||
| system.h | ||
| traditional.cc | ||
| ucnid.h | ||
| ucnid.tab | ||