diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2020-02-04 13:39:59 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@redhat.com> | 2020-02-04 13:39:59 +0100 |
| commit | f8d6e448f801bcbdaa83c98991b15ed35d1bb3cc (patch) | |
| tree | da66a93daadf495ae458d39c391afc19a358078e /libcpp/traditional.c | |
| parent | c04babd9dfa5c63c10d65f1bd3fb8cf503ab739d (diff) | |
| download | gcc-f8d6e448f801bcbdaa83c98991b15ed35d1bb3cc.zip gcc-f8d6e448f801bcbdaa83c98991b15ed35d1bb3cc.tar.gz gcc-f8d6e448f801bcbdaa83c98991b15ed35d1bb3cc.tar.bz2 | |
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.
Diffstat (limited to 'libcpp/traditional.c')
0 files changed, 0 insertions, 0 deletions