https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #15)
> Isn't it the same is true for any header that someone could create and not
> just about standard headers?
Yes.
__has_include can say the header is present (which is what it's designed to do)
and then including it could give an error because it uses 'constexpr' and you
compile with -std=c++03
Or you could include it, and it doesn't define anything, because all its
contents are hidden behind a #if __cplusplus > 201402L check (which is what
happens with libc++). So you include the header, try to use the library types
it is supposed to define, and get a compiler error.
In both cases __has_include is insufficient to tell you the header is usable.
Even if we moved our headers to separate directories, it wouldn't make
__has_include sufficient.. The intended mechanism Marc is so enamoured with
doesn't work.
My current plan to fix this is to change SD-6 so that instead of recommending
only a __has_include check, every feature has a feature-test macro, and change
the example to:
#ifdef __has_include
# if __has_include(<optional>)
# include <optional>
# if __cpp_lib_optional >= nnnn
# define have_optional 1
# #endif
# elif __has_include(<experimental/optional>)
# include <experimental/optional>
# if __cpp_lib_experimental_optional >= nnnn
# define have_optional 1
# define experimental_optional
# #endif
# endif
#endif
#ifndef have_optional
# define have_optional 0
#endif
Then we can change our headers to remove the #error and conditionally define a
__cpp_lib_xxx macro. Then the presence/absence of the __cpp_lib_xxx macro
indicates whether the header is actually usable, not just present on the
filesystem.
