[Bug libstdc++/79433] __has_include(<new header>) is true but #include <new header> gives #error when -std=old

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
#ifdef __has_include
#if __has_include(<variant>)
#include <variant>
std::variant<int> v;
#endif
#endif
int main(){ }

Compiling this program with g++ -std=c++14 (using libstdc++) gives:

In file included from /opt/wandbox/gcc-head/include/c++/7.0.1/variant:35:0,
                 from prog.cc:3:
/opt/wandbox/gcc-head/include/c++/7.0.1/bits/c++17_warning.h:32:2:
error: #error This file requires compiler and library support for the
ISO C++ 2017 standard. This support must be enabled with the
-std=c++17 or -std=gnu++17 compiler options.
 #error This file requires compiler and library support \
  ^~~~~
prog.cc:4:6: error: 'variant' in namespace 'std' does not name a template type
 std::variant<int> v;
      ^~~~~~~

Live demo: http://melpon.org/wandbox/permlink/qwYfRA1FPBsIsCXi

And with clang++ -std=c++14 (using libc++):

prog.cc:4:6: error: no type named 'variant' in namespace 'std'
std::variant<int> v;
~~~~~^

Live demo: http://melpon.org/wandbox/permlink/GTrG5HpX1lCT07Dx

Just removing the #error from our headers isn't going to make the check work
portably. Having per-dialect directories for libstdc++ isn't going to help it
work with libc++ (and the libc++ devs have rejected the idea of doing that for
libc++).

Despite what comment 1 says, the best solution today is to also check
__cplusplus (oh, but that macro wasn't right 5 years ago is a silly argument,
none of these headers existed 5 years ago anyway). If you check __cplusplus
then the #error in our headers isn't a problem.