On Tue, 12 Dec 2023, Lewis Hyatt wrote: > 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.
OK. -- Joseph S. Myers josmy...@redhat.com