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

Reply via email to