The issue was that `capture_by_value` was meant to be specialized
by plain type, e.g. `capture_by_value<std::weak_ordering>`, but
the TMP in Decomposer did not properly throw away `const` (and
`volatile`) qualifiers, before taking the value of `capture_by_value`.
Our implementation should be slightly faster, and has the
advantage of being consistent between platforms. This does not
have immediate user impact, because we currently use random_device
to generate random seed for resampling, but if we decide to change
this in the future, it is one less place to fix.
Now we use intrinsics when possible, and fallback to optimized
implementation in portable C++. The difference is about 4x when
we can use intrinsics and about 2x when we cannot.
This should speed up our Lemire's algorithm implementation nicely.
The previously used `make_unsigned` approach combined with the overload
set of `extendedMult` caused compilation issues on MacOS platform. By
forcing the selection to be one of `std::uintX_t` types we don't need
to complicate the overload set further.
Previously it could be just plain reporter name, e.g. `xml`, but
it could not specify other reporter options. This change is not
particularly useful for the built-in reporters, as it mostly comes
in handy for combining specific custom reporter with custom arguments,
and the built-in reporters do not have those.
Previously these were removed in bbba3d8a06,
to allow Decomposer changes that were not compatible with old
GCCs. However, the compatibility was restored in
459ac8562b, and so we can restore
the builds again.
This target previously did not specify its minimum C++ standard.
AppleClang was emitting warnings about the use of C++11 features
which is fixed by telling CMake that this target requires C++14.
Because this target does not link to the existing CMake targets
it never inherited that C++ standard requirement.
* Improve Conan recipe support
* export files
* supports c++14
* update Conan client in the CI
* Better compatibility with Conan 1.x
* Manage options and cppstd for Conan 1.x
* copy eveything from extra
Signed-off-by: Uilian Ries <uilianries@gmail.com>
The Core Guidelines state "A base class destructor should be either
public and virtual, or protected and non-virtual" so, hopefully, no
static analyser will complain.
INTERFACE should be used on dependencies from other than our source files.
PRIVATE should be used the include happens in our source files.
In this case (src/catch2/internal/catch_debug_console.cpp:20) the include
is from our source file.
I encountered a issue with this when building Catch2 for Android in
combination with BUILD_SHARED_LIBS. Changing the visibility to PRIVATE
fixes the issue.
* Removed Conan1 build.py file using conan package tools that are no longer supported
* Working conan 1 and 2 build with the test package.
updated the test_package to be updated to conan 2 and fixed missing cmake. Still need to check that the license file is packaged up and that the packages look identical before the changes
* Removing debug prints and the license check that isn't working yet
* Working license file copied over as it was before
* Migrated the properties of cpp_info to conan 2. Keeping conan 1 support by checking the version of conan
https://docs.conan.io/1/migrating_to_2.0/properties.html
* Revert "Removed Conan1 build.py file using conan package tools that are no longer supported"
This reverts commit a606d1dfe6.
* Need to add a set_version to parse the version from CMakeLists.txt
Adding a package build yaml to ensure conan keeps building on 1 and 2
* Setting lowercase catch2 for pkg_config and cmake_target_name
* Fixing the namespace for conan file cmake_target_name
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)`.
