STL: Update __cpp_lib_concepts conditionals when all supported C++20 frontends support Concepts
#395
Closed
2 of 3 tasks
Labels
Comments
CaseyCarter
added
enhancement
CaseyCarter
changed the title
__cpp_lib_concepts conditionals when supported C++20 frontends support concepts
4 tasks
5 tasks
|
From #1648 (comment):
|
StephanTLavavej
added a commit
to StephanTLavavej/STL
that referenced
this issue
Aug 4, 2022
CaseyCarter
changed the title
__cpp_lib_concepts conditionals when all supported C++20 frontends support Concepts
CaseyCarter
added a commit
to CaseyCarter/STL
that referenced
this issue
Aug 24, 2022
We should try to minimize the number of feature-test macros used to guard conditionally-compiled product code, so that readers aren't required to memorize the content of SD-6 in order to comprehend the STL. Consequently, feature-test macros should only be used in product code when their values are not implied by language mode or a conjunction of language mode and some other feature-test macro. We should instead test `_HAS_CXXYY && defined(__other_feature_macro)` directly. Feature-test macros whose values vary according to compiler flags other than language modes, or for features that aren't yet implemented by all compilers should be tested directly (although latter will eventually be replace by langage mode tests when the minimum required versions of all supported compilers implement the feature). Some consequences of these rules: * `_HAS_CXX20 && defined(__cpp_lib_concepts)` is redundant since `defined(__cpp_lib_concepts)` implies `_HAS_CXX20`. * `_HAS_CXX20` implies `__cpp_constexpr_dynamic_alloc` now that all supported C++20 front ends implement that feature * `defined(__cpp_lib_concepts)` implies `defined(__cpp_lib_format)` * `_HAS_CXX23 && defined(__cpp_lib_concepts)` implies `defined(__cpp_expected)` and `defined(__cpp_lib_containers_ranges)` [Note that we don't annotate plain `defined(__cpp_lib_concepts)` with `// TRANSITION, microsoftGH-395` in product because microsoftGH-395 clearly indicates that all such tests should be replaced and we don't want to churn just to add the annotation.]
CaseyCarter
added a commit
to CaseyCarter/STL
that referenced
this issue
Aug 25, 2022
* remove redundant nested `_HAS_CXX23`s * remove `// TRANSITION, microsoftGH-395` from `#ifn?def __cpp_lib_concepts` for consistency * don't be lazy and use `// TRANSITION, microsoftGH-395` as an `#endif` comment instead of the actual test condition
cpplearner
added a commit
to cpplearner/STL
that referenced
this issue
Jan 4, 2024
The following substitutions are performed: - `#elif _HAS_CXX20 && defined(__cpp_lib_concepts) // TRANSITION, microsoftGH-395` => `#elif _HAS_CXX20` - `#elif defined(__cpp_lib_concepts)` => `#elif _HAS_CXX20` - `#else // ^^^ !defined(__cpp_lib_concepts) / defined(__cpp_lib_concepts) vvv` => `#else // ^^^ !_HAS_CXX20 / _HAS_CXX20 vvv` - `#else // ^^^ _HAS_CXX20 && !defined(__cpp_lib_concepts) / !_HAS_CXX20 vvv` => `#else // ^^^ _HAS_CXX20 / !_HAS_CXX20 vvv` - `#else // ^^^ defined(__cpp_lib_concepts) / !defined(__cpp_lib_concepts) vvv` => `#else // ^^^ _HAS_CXX20 / !_HAS_CXX20 vvv` - `#endif // !_HAS_CXX20 || !defined(__cpp_lib_concepts)` => `#endif // !_HAS_CXX20` - `#endif // ^^^ !defined(__cpp_lib_concepts) ^^^` => `#endif // ^^^ !_HAS_CXX20 ^^^` - `#endif // ^^^ defined(__cpp_lib_concepts) ^^^` => `#endif // ^^^ _HAS_CXX20 ^^^` - `#endif // _HAS_CXX20 && defined(__cpp_lib_concepts)` => `#endif // _HAS_CXX20` - `#endif // _HAS_CXX23 && defined(__cpp_lib_concepts)` => `#endif // _HAS_CXX23` - `#endif // _HAS_CXX23 && defined(__cpp_lib_concepts) // TRANSITION, microsoftGH-395` => `#endif // _HAS_CXX23` - `#endif // __cpp_lib_concepts` => `#endif // _HAS_CXX20` - `#endif // defined(__cpp_lib_concepts)` => `#endif // _HAS_CXX20` - `#endif // defined(__cpp_lib_concepts) && _HAS_CXX23` => `#endif // _HAS_CXX23` - `#if !_HAS_CXX20 || !defined(__cpp_lib_concepts) // TRANSITION, microsoftGH-395` => `#if !_HAS_CXX20` - `#if !_HAS_CXX23 || !defined(__cpp_lib_concepts) // TRANSITION, microsoftGH-395` => `#if !_HAS_CXX23` - `#if _HAS_CXX20 && defined(__cpp_lib_concepts) // TRANSITION, microsoftGH-395` => `#if _HAS_CXX20` - `#if _HAS_CXX23 && defined(__cpp_lib_concepts) // TRANSITION, microsoftGH-395` => `#if _HAS_CXX23` - `#if _HAS_CXX23 && defined(__cpp_lib_concepts)` => `#if _HAS_CXX23` - `#if defined(__cpp_lib_concepts) && _HAS_CXX23` => `#if _HAS_CXX23` - `#if defined(__cpp_lib_concepts) // TRANSITION, microsoftGH-395` => `#if _HAS_CXX20` - `#if defined(__cpp_lib_concepts)` => `#if _HAS_CXX20` - `#ifdef __cpp_lib_concepts // TRANSITION, microsoftGH-395` => `#if _HAS_CXX20` - `#ifdef __cpp_lib_concepts` => `#if _HAS_CXX20` - `#ifndef __cpp_lib_concepts` => `#if !_HAS_CXX20`
cpplearner
added a commit
to cpplearner/STL
that referenced
this issue
Jan 4, 2024
cpplearner
added a commit
to cpplearner/STL
that referenced
this issue
Jan 9, 2024
StephanTLavavej
added
fixed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Quite a bit of C++20-only code in the STL which uses C++20's Concepts feature is currently guarded with
#ifdef __cpp_lib_concepts.__cpp_lib_conceptsis defined in<yvals_core.h>only if__cpp_conceptsis defined, so the result is that parts of the library that need concepts are only available if the compiler supports concepts.Once our C++20-supported compilers (MSVC, IntelliSense (EDG), and Clang) all support concepts, each occurrence of
#ifdef __cpp_lib_conceptscan and should be replaced with#if _HAS_CXX20. Occurrences of#if _HAS_CXX20resulting from this process that are nested within#if _HAS_CXX20or#if _HAS_CXX23can then be made unconditional.The text was updated successfully, but these errors were encountered: