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. |
||
---|---|---|
.. | ||
diagnostic-pragma-1.c | ||
diagnostic-pragma-2.c | ||
ffile-prefix-map.c | ||
fmacro-prefix-map.c | ||
fmax-include-depth-1a.h | ||
fmax-include-depth-1b.h | ||
fmax-include-depth.c | ||
has-builtin-2.c | ||
has-builtin-3.c | ||
has-builtin.c | ||
has-include-1.c | ||
has-include-next-1.c | ||
line-1.c | ||
macro-arg-count-1.c | ||
macro-arg-count-2.c | ||
normalize-3.c | ||
openacc-define-1.c | ||
openacc-define-2.c | ||
openacc-define-3.c | ||
openmp-define-1.c | ||
openmp-define-2.c | ||
openmp-define-3.c | ||
pr45457.c | ||
pr57580.c | ||
pr58844-1.c | ||
pr58844-2.c | ||
pr60400-1.h | ||
pr60400-2.h | ||
pr60400.c | ||
pr63831-1.c | ||
pr63831-2.c | ||
pr65238-1.c | ||
pr88974.c | ||
pr91639-one.h | ||
pr91639-two.h | ||
pr91639.c | ||
pr92296-1.c | ||
pr92296-2.c | ||
pr93452-1.c | ||
pr93452-2.c | ||
pr93545-1.c | ||
pr93545-2.c | ||
pr93545-3.c | ||
pr93545-4.c | ||
spaceship-1.c | ||
ucnid-2011-1-utf8.c | ||
ucnid-2011-1.c | ||
va-opt-2.c | ||
va-opt-3.c | ||
va-opt-error.c | ||
va-opt-pedantic.c | ||
va-opt.c | ||
warning-directive-1.c | ||
warning-directive-2.c | ||
warning-directive-3.c | ||
warning-directive-4.c | ||
warning-zero-in-literals-1.c | ||
warning-zero-location-2.c | ||
warning-zero-location.c |