3rd-party
/
catch2
mirror of https://github.com/catchorg/Catch2.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
catch2/tests/SelfTest/helpers/type_with_lit_0_comparisons...

50 lines
1.8 KiB
C++
Raw Normal View History

Support decomposing types that only compare with literal 0 This is primarily done to support new `std::*_ordering` types, but the refactoring also supports any other type with this property. The compilation overhead is surprisingly low. Testing it with clang on a Linux machine, compiling our SelfTest project takes only 2-3% longer with these changes than it takes otherwise. Closes #2555
2022-11-01 15:01:43 +01:00
// Copyright Catch2 Authors
// Distributed under the Boost Software License, Version 1.0.
// (See accompanying file LICENSE.txt or copy at
// https://www.boost.org/LICENSE_1_0.txt)
// SPDX-License-Identifier: BSL-1.0
#ifndef CATCH_TEST_HELPERS_TYPE_WITH_LIT_0_COMPARISONS_HPP_INCLUDED
#define CATCH_TEST_HELPERS_TYPE_WITH_LIT_0_COMPARISONS_HPP_INCLUDED
#include <type_traits>
// Should only be constructible from literal 0.
Support literal-zero detectors using consteval int constructors This was originally motivated by `REQUIRE((a <=> b) == 0)` no longer compiling using MSVC. After some investigation, I found that they changed their implementation of the zero literal detector from the previous pointer-constructor with deleted other constructors, into one that uses `consteval` constructor from int. This breaks the previous detection logic, because now `is_foo_comparable<std::strong_ordering, int>` is true, but actually trying to compare them is a compile-time error... The solution was to make the decomposition `constexpr` and rely on a late C++20 DR that makes it so that `consteval` propagates up through the callstack of `constexpr` functions, until it either runs out of `constexpr` functions, or succeeds. However, the default handling of types in decomposition is to take a reference to them. This reference never becomes dangling, but because the constexpr evaluation engine cannot prove this, decomposition paths taking references to objects cannot be actually evaluated at compilation time. Thankfully we already did have a value-oriented decomposition path for arithmetic types (as these are common linkage-less types), so we could just explicitly spell out the `std::foo_ordering` types as also being supposed to be decomposed by-value. Two more fun facts about these changes 1) The original motivation of the MSVC change was to avoid trigering a `Wzero-as-null-pointer-constant` warning. I still do not believe this was a good decision. 2) Current latest version of MSVC does not actually implement the aforementioned C++20 DR, so even with this commit, MSVC cannot compile `REQUIRE((a <=> b) == 0)`.
2024-02-08 22:21:18 +01:00
// Based on the constructor from pointer trick, used by libstdc++ and libc++
// (formerly also MSVC, but they've moved to consteval int constructor).
Support decomposing types that only compare with literal 0 This is primarily done to support new `std::*_ordering` types, but the refactoring also supports any other type with this property. The compilation overhead is surprisingly low. Testing it with clang on a Linux machine, compiling our SelfTest project takes only 2-3% longer with these changes than it takes otherwise. Closes #2555
2022-11-01 15:01:43 +01:00
// Used by `TypeWithLit0Comparisons` for testing comparison
// ops that only work with literal zero, the way std::*orderings do
Support literal-zero detectors using consteval int constructors This was originally motivated by `REQUIRE((a <=> b) == 0)` no longer compiling using MSVC. After some investigation, I found that they changed their implementation of the zero literal detector from the previous pointer-constructor with deleted other constructors, into one that uses `consteval` constructor from int. This breaks the previous detection logic, because now `is_foo_comparable<std::strong_ordering, int>` is true, but actually trying to compare them is a compile-time error... The solution was to make the decomposition `constexpr` and rely on a late C++20 DR that makes it so that `consteval` propagates up through the callstack of `constexpr` functions, until it either runs out of `constexpr` functions, or succeeds. However, the default handling of types in decomposition is to take a reference to them. This reference never becomes dangling, but because the constexpr evaluation engine cannot prove this, decomposition paths taking references to objects cannot be actually evaluated at compilation time. Thankfully we already did have a value-oriented decomposition path for arithmetic types (as these are common linkage-less types), so we could just explicitly spell out the `std::foo_ordering` types as also being supposed to be decomposed by-value. Two more fun facts about these changes 1) The original motivation of the MSVC change was to avoid trigering a `Wzero-as-null-pointer-constant` warning. I still do not believe this was a good decision. 2) Current latest version of MSVC does not actually implement the aforementioned C++20 DR, so even with this commit, MSVC cannot compile `REQUIRE((a <=> b) == 0)`.
2024-02-08 22:21:18 +01:00
struct ZeroLiteralAsPointer {
constexpr ZeroLiteralAsPointer( ZeroLiteralAsPointer* ) noexcept {}
Support decomposing types that only compare with literal 0 This is primarily done to support new `std::*_ordering` types, but the refactoring also supports any other type with this property. The compilation overhead is surprisingly low. Testing it with clang on a Linux machine, compiling our SelfTest project takes only 2-3% longer with these changes than it takes otherwise. Closes #2555
2022-11-01 15:01:43 +01:00
template <typename T,
typename = std::enable_if_t<!std::is_same<T, int>::value>>
Support literal-zero detectors using consteval int constructors This was originally motivated by `REQUIRE((a <=> b) == 0)` no longer compiling using MSVC. After some investigation, I found that they changed their implementation of the zero literal detector from the previous pointer-constructor with deleted other constructors, into one that uses `consteval` constructor from int. This breaks the previous detection logic, because now `is_foo_comparable<std::strong_ordering, int>` is true, but actually trying to compare them is a compile-time error... The solution was to make the decomposition `constexpr` and rely on a late C++20 DR that makes it so that `consteval` propagates up through the callstack of `constexpr` functions, until it either runs out of `constexpr` functions, or succeeds. However, the default handling of types in decomposition is to take a reference to them. This reference never becomes dangling, but because the constexpr evaluation engine cannot prove this, decomposition paths taking references to objects cannot be actually evaluated at compilation time. Thankfully we already did have a value-oriented decomposition path for arithmetic types (as these are common linkage-less types), so we could just explicitly spell out the `std::foo_ordering` types as also being supposed to be decomposed by-value. Two more fun facts about these changes 1) The original motivation of the MSVC change was to avoid trigering a `Wzero-as-null-pointer-constant` warning. I still do not believe this was a good decision. 2) Current latest version of MSVC does not actually implement the aforementioned C++20 DR, so even with this commit, MSVC cannot compile `REQUIRE((a <=> b) == 0)`.
2024-02-08 22:21:18 +01:00
constexpr ZeroLiteralAsPointer( T ) = delete;
Support decomposing types that only compare with literal 0 This is primarily done to support new `std::*_ordering` types, but the refactoring also supports any other type with this property. The compilation overhead is surprisingly low. Testing it with clang on a Linux machine, compiling our SelfTest project takes only 2-3% longer with these changes than it takes otherwise. Closes #2555
2022-11-01 15:01:43 +01:00
};
Support literal-zero detectors using consteval int constructors This was originally motivated by `REQUIRE((a <=> b) == 0)` no longer compiling using MSVC. After some investigation, I found that they changed their implementation of the zero literal detector from the previous pointer-constructor with deleted other constructors, into one that uses `consteval` constructor from int. This breaks the previous detection logic, because now `is_foo_comparable<std::strong_ordering, int>` is true, but actually trying to compare them is a compile-time error... The solution was to make the decomposition `constexpr` and rely on a late C++20 DR that makes it so that `consteval` propagates up through the callstack of `constexpr` functions, until it either runs out of `constexpr` functions, or succeeds. However, the default handling of types in decomposition is to take a reference to them. This reference never becomes dangling, but because the constexpr evaluation engine cannot prove this, decomposition paths taking references to objects cannot be actually evaluated at compilation time. Thankfully we already did have a value-oriented decomposition path for arithmetic types (as these are common linkage-less types), so we could just explicitly spell out the `std::foo_ordering` types as also being supposed to be decomposed by-value. Two more fun facts about these changes 1) The original motivation of the MSVC change was to avoid trigering a `Wzero-as-null-pointer-constant` warning. I still do not believe this was a good decision. 2) Current latest version of MSVC does not actually implement the aforementioned C++20 DR, so even with this commit, MSVC cannot compile `REQUIRE((a <=> b) == 0)`.
2024-02-08 22:21:18 +01:00
Support decomposing types that only compare with literal 0 This is primarily done to support new `std::*_ordering` types, but the refactoring also supports any other type with this property. The compilation overhead is surprisingly low. Testing it with clang on a Linux machine, compiling our SelfTest project takes only 2-3% longer with these changes than it takes otherwise. Closes #2555
2022-11-01 15:01:43 +01:00
struct TypeWithLit0Comparisons {
Support literal-zero detectors using consteval int constructors This was originally motivated by `REQUIRE((a <=> b) == 0)` no longer compiling using MSVC. After some investigation, I found that they changed their implementation of the zero literal detector from the previous pointer-constructor with deleted other constructors, into one that uses `consteval` constructor from int. This breaks the previous detection logic, because now `is_foo_comparable<std::strong_ordering, int>` is true, but actually trying to compare them is a compile-time error... The solution was to make the decomposition `constexpr` and rely on a late C++20 DR that makes it so that `consteval` propagates up through the callstack of `constexpr` functions, until it either runs out of `constexpr` functions, or succeeds. However, the default handling of types in decomposition is to take a reference to them. This reference never becomes dangling, but because the constexpr evaluation engine cannot prove this, decomposition paths taking references to objects cannot be actually evaluated at compilation time. Thankfully we already did have a value-oriented decomposition path for arithmetic types (as these are common linkage-less types), so we could just explicitly spell out the `std::foo_ordering` types as also being supposed to be decomposed by-value. Two more fun facts about these changes 1) The original motivation of the MSVC change was to avoid trigering a `Wzero-as-null-pointer-constant` warning. I still do not believe this was a good decision. 2) Current latest version of MSVC does not actually implement the aforementioned C++20 DR, so even with this commit, MSVC cannot compile `REQUIRE((a <=> b) == 0)`.
2024-02-08 22:21:18 +01:00
#define DEFINE_COMP_OP( op ) \
constexpr friend bool operator op( TypeWithLit0Comparisons, \
ZeroLiteralAsPointer ) { \
return true; \
} \
constexpr friend bool operator op( ZeroLiteralAsPointer, \
TypeWithLit0Comparisons ) { \
return false; \
Support decomposing types that only compare with literal 0 This is primarily done to support new `std::*_ordering` types, but the refactoring also supports any other type with this property. The compilation overhead is surprisingly low. Testing it with clang on a Linux machine, compiling our SelfTest project takes only 2-3% longer with these changes than it takes otherwise. Closes #2555
2022-11-01 15:01:43 +01:00
}
DEFINE_COMP_OP( < )
DEFINE_COMP_OP( <= )
DEFINE_COMP_OP( > )
DEFINE_COMP_OP( >= )
DEFINE_COMP_OP( == )
DEFINE_COMP_OP( != )
#undef DEFINE_COMP_OP
};
#endif // CATCH_TEST_HELPERS_TYPE_WITH_LIT_0_COMPARISONS_HPP_INCLUDED