procyberian/gcc
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

libcpp: Diagnose __has_include outside of preprocessor directives [PR93545]

Browse source 
The standard says http://eel.is/c++draft/cpp.cond#7.sentence-2 that
__has_include can't appear at arbitrary places in the source.  As we have
not recognized __has_include* outside of preprocessing directives in the
past, accepting it there now would be a regression.  The patch does still
allow it in #define if it is then used in preprocessing directives, I guess
that use isn't strictly valid either, but clang seems to accept it.

2020-02-04  Jakub Jelinek  <jakub@redhat.com>

	* macro.c (builtin_has_include): Diagnose __has_include* use outside
	of preprocessing directives.

	* c-c++-common/cpp/has-include-1.c: New test.
	* c-c++-common/cpp/has-include-next-1.c: New test.
	* c-c++-common/gomp/has-include-1.c: New test.
This commit is contained in:
Jakub Jelinek 2020-02-04 13:39:59 +01:00
parent c04babd9df
commit f8d6e448f8
5 changed files with 220 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

3
libcpp/ChangeLog
View file

@ -1,5 +1,8 @@
2020-02-04 Jakub Jelinek <jakub@redhat.com>
* macro.c (builtin_has_include): Diagnose __has_include* use outside
of preprocessing directives.
PR preprocessor/93545
* macro.c (cpp_get_token_no_padding): New function.
(builtin_has_include): Use it instead of cpp_get_token. Don't check

5
libcpp/macro.c
View file

@ -359,6 +359,11 @@ builtin_has_include (cpp_reader *pfile, cpp_hashnode *op, bool has_next)
{
int result = 0;
if (!pfile->state.in_directive)
cpp_error (pfile, CPP_DL_ERROR,
"\"%s\" used outside of preprocessing directive",
NODE_NAME (op));
pfile->state.angled_headers = true;
const cpp_token *token = cpp_get_token_no_padding (pfile);
bool paren = token->type == CPP_OPEN_PAREN;