This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] PR libstdc++/79433 no #error for including headers with wrong -std


As discussed in PR 79433, the recommended way to test for new features
such as std::optional has problems. The current version of SD-6 at
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations
says to simply check __has_include(optional). This test will be true
even when using -std=c++98, but actually including the header gives an
error. This works OK for ahead-of-time autoconf-style checks, but not
for preprocessor-based checks directly in the source code.

The latest draft of SD-6 (to be published soon) changes the
recommendation to use __has_include, then include the header and also
check for a feature-test macro e.g.

#ifdef __has_include
# if __has_include(optional)
#  include <optional>
#  if __cpp_lib_optional >= 201606
#   define HAVE_STD_OPTIONAL
#  endif
# endif
#endif

For this to work we need to make including <optional> always valid
(even in C++{98,03,11,14} modes) instead of failing with #error. When
included pre-C++17 the header should be empty, and specifically not
define the __cpp_lib_optional macro.

This implements that change. The <shared_mutex> header is also
affected for C++14, as that defines std::shared_timed_mutex in C++14
mode, and adds std::shared_mutex in C++17 mode.

With this change nothing else includes c++17_warning.h so we can
remove it.

In a follow-up patch I plan to do the same for the <experimental/*>
headers. The TS documents already give a macro for every header, and
LibFundTS suggests testing both __has_include and a macro, see ¶3 at
https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#general.feature.test

I'm not touching any of the headers added for C++11 (<forward_list>
etc.) because I think any user code that is relying on __has_include
will be using a std::lib with full C++11 support anyway.

Does anybody object to this change? Is getting a #error still useful,
given the existence of __has_include and __cpp_lib macros?


Attachment: patch.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]