[Bug preprocessor/80005] cpp expands __has_include() filename parts

[zackw at panix dot com]

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

Zack Weinberg <zackw at panix dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2019-06-12
                 CC|                            |zackw at panix dot com
     Ever confirmed|0                           |1

--- Comment #1 from Zack Weinberg <zackw at panix dot com> ---
Confirming.  This has now bitten an attempt to use __has_include in glibc, see
discussion starting at
https://sourceware.org/ml/libc-alpha/2019-06/msg00254.html .

The proper fix, IMO, would be to apply the same special tokenization rules to
the argument of __has_include that are used for the argument of #include. This
is not exactly the same as "don't macro-expand the argument."  Rather, in

  #if !__has_include(<linux/memfd.h>)

the character sequence <linux/memfd.h> should be processed as a single
"h-char-sequence" token, in the language of C99 6.10.2.  So there never is a
"linux" identifier token to macro-expand (nor is there a "memfd" or "h"
identifier).

However, if we instead have

  #define HEADER_TO_LOOK_FOR "special.h"
  #if __has_include (HEADER_TO_LOOK_FOR)

then HEADER_TO_LOOK_FOR should be macro-expanded.

Also, h-char-sequences and q-char-sequences are not string literals.  For
example, if we have

  #if __has_include("X11\Xlib.h")

the \X is _not_ an ill-formed escape sequence.