couchbase 4.2.1 → 4.2.3

package/deps/couchbase-cxx-client/third_party/catch2/docs/contributing.md

@@ -21,8 +21,8 @@ to the codebase itself.
 
 ## Using Git(Hub)
 
-Ongoing development happens in the `v2.x` branch for Catch2 v2, and in
-`devel` for the next major version, v3.
+Ongoing development happens in the `devel` branch for Catch2 v3, and in
+`v2.x` for maintenance updates to the v2 versions.
 
 Commits should be small and atomic. A commit is atomic when, after it is
 applied, the codebase, tests and all, still works as expected. Small
@@ -30,8 +30,8 @@ commits are also preferred, as they make later operations with git history,
 whether it is bisecting, reverting, or something else, easier.
 
 _When submitting a pull request please do not include changes to the
-single include. This means do not include them in your git commits!_
-
+amalgamated distribution files. This means do not include them in your
+git commits!_
 
 When addressing review comments in a MR, please do not rebase/squash the
 commits immediately. Doing so makes it harder to review the new changes,
@@ -55,6 +55,15 @@ tests from `SelfTest` through a specific reporter and then compare the
 generated output with a known good output ("Baseline"). By default, new
 tests should be placed here.
 
+To configure a Catch2 build with just the basic tests, use the `basic-tests`
+preset, like so:
+
+```
+# Assuming you are in Catch2's root folder
+
+cmake -B basic-test-build -S . -DCMAKE_BUILD_TYPE=Debug --preset basic-tests
+```
+
 However, not all tests can be written as plain unit tests. For example,
 checking that Catch2 orders tests randomly when asked to, and that this
 random ordering is subset-invariant, is better done as an integration
@@ -62,43 +71,62 @@ test using an external check script. Catch2 integration tests are written
 using CTest, either as a direct command invocation + pass/fail regex,
 or by delegating the check to a Python script.
 
-There are also two more kinds of tests, examples and "ExtraTests".
-Examples serve as a compilation test on the single-header distribution,
-and present a small and self-contained snippets of using Catch2 for
-writing tests. ExtraTests then are tests that either take a long time
-to run, or require separate compilation, e.g. because of testing compile
-time configuration options, and take a long time because of that.
+Catch2 is slowly gaining more and more types of tests, currently Catch2
+project also has buildable examples, "ExtraTests", and CMake config tests.
+Examples present a small and self-contained snippets of code that
+use Catch2's facilities for specific purpose. Currently they are assumed
+passing if they compile.
 
-Both of these are compiled against the single-header distribution of
-Catch2, and thus might require you to regenerate it manually. This is
-done by calling the `generateSingleHeader.py` script in `scripts`.
+ExtraTests then are expensive tests, that we do not want to run all the
+time. This can be either because they take a long time to run, or because
+they take a long time to compile, e.g. because they test compile time
+configuration and require separate compilation.
 
-Examples and ExtraTests are not compiled by default. To compile them,
-add `-DCATCH_BUILD_EXAMPLES=ON` and `-DCATCH_BUILD_EXTRA_TESTS=ON` to
-the invocation of CMake configuration step.
+Finally, CMake config tests test that you set Catch2's compile-time
+configuration options through CMake, using CMake options of the same name.
 
-Bringing this all together, the steps below should configure, build,
-and run all tests in the `Debug` compilation.
+These test categories can be enabled one by one, by passing
+`-DCATCH_BUILD_EXAMPLES=ON`, `-DCATCH_BUILD_EXTRA_TESTS=ON`, and
+`-DCATCH_ENABLE_CONFIGURE_TESTS=ON` when configuring the build.
 
-1. Regenerate the single header distribution
-```
-$ cd Catch2
-$ ./scripts/generateSingleHeader.py
-```
-2. Configure the full test build
-```
-$ cmake -Bdebug-build -H. -DCMAKE_BUILD_TYPE=Debug -DCATCH_BUILD_EXAMPLES=ON -DCATCH_BUILD_EXTRA_TESTS=ON
-```
-3. Run the actual build
-```
-$ cmake --build debug-build
-```
-4. Run the tests using CTest
+Catch2 also provides a preset that promises to enable _all_ test types,
+`all-tests`.
+
+The snippet below will build & run all tests, in `Debug` compilation mode.
+
+<!-- snippet: catch2-build-and-test -->
+<a id='snippet-catch2-build-and-test'></a>
+```sh
+# 1. Regenerate the amalgamated distribution (some tests are built against it)
+./tools/scripts/generateAmalgamatedFiles.py
+
+# 2. Configure the full test build
+cmake -B debug-build -S . -DCMAKE_BUILD_TYPE=Debug --preset all-tests
+
+# 3. Run the actual build
+cmake --build debug-build
+
+# 4. Run the tests using CTest
+cd debug-build
+ctest -j 4 --output-on-failure -C Debug
 ```
-$ cd debug-build
-$ ctest -j 4 --output-on-failure -C Debug
+<sup><a href='/tools/scripts/buildAndTest.sh#L6-L19' title='File snippet `catch2-build-and-test` was extracted from'>snippet source</a> | <a href='#snippet-catch2-build-and-test' title='Navigate to start of snippet `catch2-build-and-test`'>anchor</a></sup>
+<!-- endSnippet -->
+
+For convenience, the above commands are in the script `tools/scripts/buildAndTest.sh`, and can be run like this:
+
+```bash
+cd Catch2
+./tools/scripts/buildAndTest.sh
 ```
 
+A Windows version of the script is available at `tools\scripts\buildAndTest.cmd`.
+
+If you added new tests, you will likely see `ApprovalTests` failure.
+After you check that the output difference is expected, you should
+run `tools/scripts/approve.py` to confirm them, and include these changes
+in your commit.
+
 
 ## Writing documentation
 
@@ -107,7 +135,8 @@ other people can use it as well. This section collects some technical
 information that you will need for updating Catch2's documentation, and
 possibly some generic advise as well.
 
-### Technicalities 
+
+### Technicalities
 
 First, the technicalities:
 
@@ -118,6 +147,8 @@ should use. It provides you with the top anchor mentioned to link to
 <a id="top"></a>
 # Cool feature
 
+> [Introduced](https://github.com/catchorg/Catch2/pull/123456) in Catch2 X.Y.Z
+
 Text that explains how to use the cool feature.
 
 
@@ -136,9 +167,9 @@ be replaced with the actual version upon release. There are 2 styles
 of placeholders used through the documentation, you should pick one that
 fits your text better (if in doubt, take a look at the existing version
 tags for other features).
-  * `> [Introduced](link-to-issue-or-PR) in Catch X.Y.Z` - this
+  * `> [Introduced](link-to-issue-or-PR) in Catch2 X.Y.Z` - this
   placeholder is usually used after a section heading
-  * `> X (Y and Z) was [introduced](link-to-issue-or-PR) in Catch X.Y.Z`
+  * `> X (Y and Z) was [introduced](link-to-issue-or-PR) in Catch2 X.Y.Z`
   - this placeholder is used when you need to tag a subpart of something,
   e.g. a list
 
@@ -179,6 +210,24 @@ If want to contribute code, this section contains some simple rules
 and tips on things like code formatting, code constructions to avoid,
 and so on.
 
+### C++ standard version
+
+Catch2 currently targets C++14 as the minimum supported C++ version.
+Features from higher language versions should be used only sparingly,
+when the benefits from using them outweigh the maintenance overhead.
+
+Example of good use of polyfilling features is our use of `conjunction`,
+where if available we use `std::conjunction` and otherwise provide our
+own implementation. The reason it is good is that the surface area for
+maintenance is quite small, and `std::conjunction` can directly use
+compiler built-ins, thus providing significant compilation benefits.
+
+Example of bad use of polyfilling features would be to keep around two
+sets of metaprogramming in the stringification implementation, once
+using C++14 compliant TMP and once using C++17's `if constexpr`. While
+the C++17 would provide significant compilation speedups, the maintenance
+cost would be too high.
+
 
 ### Formatting
 
@@ -199,7 +248,7 @@ are problematic and are not always caught by our CI infrastructure.
 #### Naked exceptions and exceptions-related function
 
 If you are throwing an exception, it should be done via `CATCH_ERROR`
-or `CATCH_RUNTIME_ERROR` in `catch_enforce.h`. These macros will handle
+or `CATCH_RUNTIME_ERROR` in `internal/catch_enforce.hpp`. These macros will handle
 the differences between compilation with or without exceptions for you.
 However, some platforms (IAR) also have problems with exceptions-related
 functions, such as `std::current_exceptions`. We do not have IAR in our
@@ -208,6 +257,18 @@ However, if you do, they should be kept behind a
 `CATCH_CONFIG_DISABLE_EXCEPTIONS` macro.
 
 
+#### Avoid `std::move` and `std::forward`
+
+`std::move` and `std::forward` provide nice semantic name for a specific
+`static_cast`. However, being function templates they have surprisingly
+high cost during compilation, and can also have a negative performance
+impact for low-optimization builds.
+
+You should be using `CATCH_MOVE` and `CATCH_FORWARD` macros from
+`internal/catch_move_and_forward.hpp` instead. They expand into the proper
+`static_cast`, and avoid the overhead of `std::move` and `std::forward`.
+
+
 #### Unqualified usage of functions from C's stdlib
 
 If you are using a function from C's stdlib, please include the header
@@ -216,6 +277,57 @@ there is no difference is wrong, QNX and VxWorks won't compile if you
 include the header as `<cfoo>` and call the function unqualified.
 
 
+#### User-Defined Literals (UDL) for Catch2' types
+
+Due to messy standardese and ... not great ... implementation of
+`-Wreserved-identifier` in Clang, avoid declaring UDLs as
+```cpp
+Approx operator "" _a(long double);
+```
+and instead declare them as
+```cpp
+Approx operator ""_a(long double);
+```
+
+Notice that the second version does not have a space between the `""` and
+the literal suffix.
+
+
+
+### New source file template
+
+If you are adding new source file, there is a template you should use.
+Specifically, every source file should start with the licence header:
+```cpp
+
+    //              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
+```
+
+The include guards for header files should follow the pattern `{FILENAME}_INCLUDED`.
+This means that for file `catch_matchers_foo.hpp`, the include guard should
+be `CATCH_MATCHERS_FOO_HPP_INCLUDED`, for `catch_generators_bar.hpp`, the include
+guard should be `CATCH_GENERATORS_BAR_HPP_INCLUDED`, and so on.
+
+
+### Adding new `CATCH_CONFIG` option
+
+When adding new `CATCH_CONFIG` option, there are multiple places to edit:
+  * `CMake/CatchConfigOptions.cmake` - this is used to generate the
+    configuration options in CMake, so that CMake frontends know about them.
+  * `docs/configuration.md` - this is where the options are documented
+  * `src/catch2/catch_user_config.hpp.in` - this is template for generating
+    `catch_user_config.hpp` which contains the materialized configuration
+  * `BUILD.bazel` - Bazel does not have configuration support like CMake,
+    and all expansions need to be done manually
+  * other files as needed, e.g. `catch2/internal/catch_config_foo.hpp`
+    for the logic that guards the configuration
+
+
 ## CoC
 
 This project has a [CoC](../CODE_OF_CONDUCT.md). Please adhere to it

package/deps/couchbase-cxx-client/third_party/catch2/docs/deprecations.md

@@ -9,69 +9,6 @@ either of these is a breaking change, and thus will not happen until
 at least the next major release.
 
 
-## Deprecations
-
-### `--list-*` return values
-
-The return codes of the `--list-*` family of command line arguments
-will no longer be equal to the number of tests/tags/etc found, instead
-it will be 0 for success and non-zero for failure.
-
-
-### `--list-test-names-only`
-
-`--list-test-names-only` command line argument will be removed.
-
-
-### `ANON_TEST_CASE`
-
-`ANON_TEST_CASE` is scheduled for removal, as it can be fully replaced
-by a `TEST_CASE` with no arguments.
-
-
-### Secondary description amongst tags
-
-Currently, the tags part of `TEST_CASE` (and others) macro can also
-contain text that is not part of tags. This text is then separated into
-a "description" of the test case, but the description is then never used
-apart from writing it out for `--list-tests -v high`.
-
-Because it isn't actually used nor documented, and brings complications
-to Catch2's internals, description support will be removed.
-
-### SourceLineInfo::empty()
-
-There should be no reason to ever have an empty `SourceLineInfo`, so the
-method will be removed.
-
-
-### Composing lvalues of already composed matchers
-
-Because a significant bug in this use case has persisted for 2+ years
-without a bug report, and to simplify the implementation, code that
-composes lvalues of composed matchers will not compile. That is,
-this code will no longer work:
-
-```cpp
-            auto m1 = Contains("string");
-            auto m2 = Contains("random");
-            auto composed1 = m1 || m2;
-            auto m3 = Contains("different");
-            auto composed2 = composed1 || m3;
-            REQUIRE_THAT(foo(), !composed1);
-            REQUIRE_THAT(foo(), composed2);
-```
-
-Instead you will have to write this:
-
-```cpp
-            auto m1 = Contains("string");
-            auto m2 = Contains("random");
-            auto m3 = Contains("different");
-            REQUIRE_THAT(foo(), !(m1 || m2));
-            REQUIRE_THAT(foo(), m1 || m2 || m3);
-```
-
 ### `ParseAndAddCatchTests.cmake`
 
 The CMake/CTest integration using `ParseAndAddCatchTests.cmake` is deprecated,
@@ -80,64 +17,23 @@ as it can be replaced by `Catch.cmake` that provides the function
 command line interface instead of parsing C++ code with regular expressions.
 
 
-## Planned changes
-
-
-### Reporter verbosities
-
-The current implementation of verbosities, where the reporter is checked
-up-front whether it supports the requested verbosity, is fundamentally
-misguided and will be changed. The new implementation will no longer check
-whether the specified reporter supports the requested verbosity, instead
-it will be up to the reporters to deal with verbosities as they see fit
-(with an expectation that unsupported verbosities will be, at most,
-warnings, but not errors).
-
-
-### Output format of `--list-*` command line parameters
-
-The various list operations will be piped through reporters. This means
-that e.g. XML reporter will write the output as machine-parseable XML,
-while the Console reporter will keep the current, human-oriented output.
-
-
-### `CHECKED_IF` and `CHECKED_ELSE`
-
-To make the `CHECKED_IF` and `CHECKED_ELSE` macros more useful, they will
-be marked as "OK to fail" (`Catch::ResultDisposition::SuppressFail` flag
-will be added), which means that their failure will not fail the test,
-making the `else` actually useful.
-
-
-### Change semantics of `[.]` and tag exclusion
-
-Currently, given these 2 tests
-```cpp
-TEST_CASE("A", "[.][foo]") {}
-TEST_CASE("B", "[.][bar]") {}
-```
-specifying `[foo]` as the testspec will run test "A" and specifying
-`~[foo]` will run test "B", even though it is hidden. Also, specifying
-`~[baz]` will run both tests. This behaviour is often surprising and will
-be changed so that hidden tests are included in a run only if they
-positively match a testspec.
-
-
-### Console Colour API
-
-The API for Catch2's console colour will be changed to take an extra
-argument, the stream to which the colour code should be applied.
-
+### `CATCH_CONFIG_BAZEL_SUPPORT`
 
-### Type erasure in the `PredicateMatcher`
+Catch2 supports writing the Bazel JUnit XML output file when it is aware
+that is within a bazel testing environment. Originally there was no way
+to accurately probe the environment for this information so the flag
+`CATCH_CONFIG_BAZEL_SUPPORT` was added. This now deprecated. Bazel has now had a change
+where it will export `BAZEL_TEST=1` for purposes like the above. Catch2
+will now instead inspect the environment instead of relying on build configuration.
 
-Currently, the `PredicateMatcher` uses `std::function` for type erasure,
-so that type of the matcher is always `PredicateMatcher<T>`, regardless
-of the type of the predicate. Because of the high compilation overhead
-of `std::function`, and the fact that the type erasure is used only rarely,
-`PredicateMatcher` will no longer be type erased in the future. Instead,
-the predicate type will be made part of the PredicateMatcher's type.
+### `IEventLister::skipTest( TestCaseInfo const& testInfo )`
 
+This event (including implementations in derived classes such as `ReporterBase`)
+is deprecated and will be removed in the next major release. It is currently
+invoked for all test cases that are not going to be executed due to the test run
+being aborted (when using `--abort` or `--abortx`). It is however
+**NOT** invoked for test cases that are [explicitly skipped using the `SKIP`
+macro](skipping-passing-failing.md#top).
 
 ---
 

package/deps/couchbase-cxx-client/third_party/catch2/docs/event-listeners.md

@@ -1,74 +1,43 @@
 <a id="top"></a>
 # Event Listeners
 
-A `Listener` is a class you can register with Catch that will then be passed events,
-such as a test case starting or ending, as they happen during a test run.
-`Listeners` are actually types of `Reporters`, with a few small differences:
- 
-1. Once registered in code they are automatically used - you don't need to specify them on the command line
-2. They are called in addition to (just before) any reporters, and you can register multiple listeners.
-3. They derive from `Catch::TestEventListenerBase`, which has default stubs for all the events,
-so you are not forced to implement events you're not interested in.
-4. You register a listener with `CATCH_REGISTER_LISTENER`
-
-
-## Implementing a Listener
-Simply derive a class from `Catch::TestEventListenerBase` and implement the methods you are interested in, either in
-the main source file (i.e. the one that defines `CATCH_CONFIG_MAIN` or `CATCH_CONFIG_RUNNER`), or in a
-file that defines `CATCH_CONFIG_EXTERNAL_INTERFACES`.
-
-Then register it using `CATCH_REGISTER_LISTENER`.
-
-For example ([complete source code](../examples/210-Evt-EventListeners.cpp)):
-
-```c++
-#define CATCH_CONFIG_MAIN
-#include "catch.hpp"
-
-struct MyListener : Catch::TestEventListenerBase {
-
-    using TestEventListenerBase::TestEventListenerBase; // inherit constructor
-
-    void testCaseStarting( Catch::TestCaseInfo const& testInfo ) override {
-        // Perform some setup before a test case is run
-    }
-    
-    void testCaseEnded( Catch::TestCaseStats const& testCaseStats ) override {
-        // Tear-down after a test case is run
+An event listener is a bit like a reporter, in that it responds to various
+reporter events in Catch2, but it is not expected to write any output.
+Instead, an event listener performs actions within the test process, such
+as performing global initialization (e.g. of a C library), or cleaning out
+in-memory logs if they are not needed (the test case passed).
+
+Unlike reporters, each registered event listener is always active. Event
+listeners are always notified before reporter(s).
+
+To write your own event listener, you should derive from `Catch::TestEventListenerBase`,
+as it provides empty stubs for all reporter events, allowing you to
+only override events you care for. Afterwards you have to register it
+with Catch2 using `CATCH_REGISTER_LISTENER` macro, so that Catch2 knows
+about it and instantiates it before running tests.
+
+Example event listener:
+```cpp
+#include <catch2/reporters/catch_reporter_event_listener.hpp>
+#include <catch2/reporters/catch_reporter_registrars.hpp>
+
+class testRunListener : public Catch::EventListenerBase {
+public:
+    using Catch::EventListenerBase::EventListenerBase;
+
+    void testRunStarting(Catch::TestRunInfo const&) override {
+        lib_foo_init();
     }
 };
-CATCH_REGISTER_LISTENER( MyListener )
-```
-
-_Note that you should not use any assertion macros within a Listener!_ 
-
-## Events that can be hooked
-
-The following are the methods that can be overridden in the Listener:
 
-```c++
-// The whole test run, starting and ending
-virtual void testRunStarting( TestRunInfo const& testRunInfo );
-virtual void testRunEnded( TestRunStats const& testRunStats );
-
-// Test cases starting and ending
-virtual void testCaseStarting( TestCaseInfo const& testInfo );
-virtual void testCaseEnded( TestCaseStats const& testCaseStats );
-
-// Sections starting and ending
-virtual void sectionStarting( SectionInfo const& sectionInfo );
-virtual void sectionEnded( SectionStats const& sectionStats );
+CATCH_REGISTER_LISTENER(testRunListener)
+```
 
-// Assertions before/ after
-virtual void assertionStarting( AssertionInfo const& assertionInfo );
-virtual bool assertionEnded( AssertionStats const& assertionStats );
+_Note that you should not use any assertion macros within a Listener!_
 
-// A test is being skipped (because it is "hidden")
-virtual void skipTest( TestCaseInfo const& testInfo );
-```
+[You can find the list of events that the listeners can react to on its
+own page](reporter-events.md#top).
 
-More information about the events (e.g. name of the test case) is contained in the structs passed as arguments -
-just look in the source code to see what fields are available. 
 
 ---
 

package/deps/couchbase-cxx-client/third_party/catch2/docs/faq.md

@@ -0,0 +1,94 @@
+<a id="top"></a>
+# Frequently Asked Questions (FAQ)
+
+**Contents**<br>
+[How do I run global setup/teardown only if tests will be run?](#how-do-i-run-global-setupteardown-only-if-tests-will-be-run)<br>
+[How do I clean up global state between running different tests?](#how-do-i-clean-up-global-state-between-running-different-tests)<br>
+[Why cannot I derive from the built-in reporters?](#why-cannot-i-derive-from-the-built-in-reporters)<br>
+[What is Catch2's ABI stability policy?](#what-is-catch2s-abi-stability-policy)<br>
+[What is Catch2's API stability policy?](#what-is-catch2s-api-stability-policy)<br>
+[Does Catch2 support running tests in parallel?](#does-catch2-support-running-tests-in-parallel)<br>
+[Can I compile Catch2 into a dynamic library?](#can-i-compile-catch2-into-a-dynamic-library)<br>
+[What repeatability guarantees does Catch2 provide?](#what-repeatability-guarantees-does-catch2-provide)<br>
+
+
+## How do I run global setup/teardown only if tests will be run?
+
+Write a custom [event listener](event-listeners.md#top) and place the
+global setup/teardown code into the `testRun*` events.
+
+
+## How do I clean up global state between running different tests?
+
+Write a custom [event listener](event-listeners.md#top) and place the
+cleanup code into either `testCase*` or `testCasePartial*` events,
+depending on how often the cleanup needs to happen.
+
+
+## Why cannot I derive from the built-in reporters?
+
+They are not made to be overridden, in that we do not attempt to maintain
+a consistent internal state if a member function is overriden, and by
+forbidding users from using them as a base class, we can refactor them
+as needed later.
+
+
+## What is Catch2's ABI stability policy?
+
+Catch2 provides no ABI stability guarantees whatsoever. Catch2 provides
+rich C++ interface, and trying to freeze its ABI would take a lot of
+pointless work.
+
+Catch2 is not designed to be distributed as dynamic library, and you
+should really be able to compile everything with the same compiler binary.
+
+
+## What is Catch2's API stability policy?
+
+Catch2 follows [semver](https://semver.org/) to the best of our ability.
+This means that we will not knowingly make backwards-incompatible changes
+without incrementing the major version number.
+
+
+## Does Catch2 support running tests in parallel?
+
+Not natively, no. We see running tests in parallel as the job of an
+external test runner, that can also run them in separate processes,
+support test execution timeouts and so on.
+
+However, Catch2 provides some tools that make the job of external test
+runners easier. [See the relevant section in our page on best
+practices](usage-tips.md#parallel-tests).
+
+
+## Can I compile Catch2 into a dynamic library?
+
+Yes, Catch2 supports the [standard CMake `BUILD_SHARED_LIBS`
+option](https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html).
+However, the dynamic library support is provided as-is. Catch2 does not
+provide API export annotations, and so you can only use it as a dynamic
+library on platforms that default to public visibility, or with tooling
+support to force export Catch2's API.
+
+
+## What repeatability guarantees does Catch2 provide?
+
+There are two places where it is meaningful to talk about Catch2's
+repeatability guarantees without taking into account user-provided
+code. First one is in the test case shuffling, and the second one is
+the output from random generators.
+
+Test case shuffling is repeatable across different platforms since v2.12.0,
+and it is also generally repeatable across versions, but we might break
+it from time to time. E.g. we broke repeatability with previous versions
+in v2.13.4 so that test cases with similar names are shuffled better.
+
+Random generators currently rely on platform's stdlib, specifically
+the distributions from `<random>`. We thus provide no extra guarantee
+above what your platform does. **Important: `<random>`'s distributions
+are not specified to be repeatable across different platforms.**
+
+
+---
+
+[Home](Readme.md#top)