From f8d6e448f801bcbdaa83c98991b15ed35d1bb3cc Mon Sep 17 00:00:00 2001
From: Jakub Jelinek <jakub@redhat.com>
Date: Tue, 4 Feb 2020 13:39:59 +0100
Subject: libcpp: Diagnose __has_include outside of preprocessor directives
[PR93545]
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.
---
libcpp/ChangeLog | 3 +++
libcpp/macro.c | 5 +++++
2 files changed, 8 insertions(+)
(limited to 'libcpp')
diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog
index 11c0773..cc5c575 100644
--- a/libcpp/ChangeLog
+++ b/libcpp/ChangeLog
@@ -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
diff --git a/libcpp/macro.c b/libcpp/macro.c
index 9f9f831..ec00307 100644
--- a/libcpp/macro.c
+++ b/libcpp/macro.c
@@ -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;
--
cgit v1.1