[Bug preprocessor/121508] ICE after error with __has_include

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

Léo Hardt <leom.hardt at inf dot ufrgs.br> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |leom.hardt at inf dot ufrgs.br

--- Comment #3 from Léo Hardt <leom.hardt at inf dot ufrgs.br> ---
Hello, everyone,

Here are some smaller code variations which also cause the same crash:

(A)   
    int i =   __has_include(<__int16_t
(B)
    int i =   __has_include(<__int16_t)
(C)
    int i =   __has_embed(<__int16_t
(D)
    int i =   __has_embed(<__int16_t)
(E)
    int i =   __has_embed(<__int16_t  + 1 + 2 + 3


Notice that both "builtin_has_include" and "builtin_has_embed" share code in
"builtin_has_include_1".


For the case "A" above:

The last token of the file is read inside 'builtin_has_include_1', and then:

1. _cpp_lex_token returns EOF
2. _cpp_pop_buffer is called. 

   Since we reached the end of the user-supplied file, now, pfile->buffer is
null.

3. builtin_has_include_1 returns the name of the parameter correctly as
"__int16_t".
4. Since builtin_has_include_1 returns a valid string, builtin_has_include
thinks
   parsing is going normally, and tries to fetch the closing parenthesis token. 

5. Since we are trying to get a new token, but pfile->buffer is already null,
   we encounter an ICE on the line

  if (paren
      && _cpp_get_token_no_padding (pfile)->type != CPP_CLOSE_PAREN)


The quickest possible fix is to add "&& pfile->buffer"  to the condition above.

Perhaps it would also be good to add a "gcc_assert(pfile);
gcc_assert(pfile->buffer)" to _cpp_lex_direct as well.