diff options
author | Lewis Hyatt <lhyatt@gmail.com> | 2023-12-12 17:46:36 -0500 |
---|---|---|
committer | Lewis Hyatt <lhyatt@gmail.com> | 2024-03-14 07:33:02 -0400 |
commit | 942497ad74272e0ef16020d628e471c5f21474b0 (patch) | |
tree | 4eeaf9038cc0ecf82b504ab914d16082fe5d8e7f /ltversion.m4 | |
parent | 6c166e55b15894ceb07dcc7b55f900e50e24ec5b (diff) | |
download | gcc-942497ad74272e0ef16020d628e471c5f21474b0.zip gcc-942497ad74272e0ef16020d628e471c5f21474b0.tar.gz gcc-942497ad74272e0ef16020d628e471c5f21474b0.tar.bz2 |
libcpp: Fix macro expansion for argument of __has_include [PR110558]
When the file name for a #include directive is the result of stringifying a
macro argument, libcpp needs to take some care to get the whitespace
correct; in particular stringify_arg() needs to see a CPP_PADDING token
between macro tokens so that it can figure out when to output space between
tokens. The CPP_PADDING tokens are not normally generated when handling a
preprocessor directive, but for #include-like directives, libcpp sets the
state variable pfile->state.directive_wants_padding to TRUE so that the
CPP_PADDING tokens will be output, and then everything works fine for
computed includes.
As the PR points out, things do not work fine for __has_include. Fix that by
setting the state variable the same as is done for #include.
libcpp/ChangeLog:
PR preprocessor/110558
* macro.cc (builtin_has_include): Set
pfile->state.directive_wants_padding prior to lexing the
file name, in case it comes from macro expansion.
gcc/testsuite/ChangeLog:
PR preprocessor/110558
* c-c++-common/cpp/has-include-2.c: New test.
* c-c++-common/cpp/has-include-2.h: New test.
Diffstat (limited to 'ltversion.m4')
0 files changed, 0 insertions, 0 deletions