Fix minor typos in documentation (#2769)

Co-authored-by: Martin Hořeňovský <martin.horenovsky@gmail.com>

docs/cmake-integration.md

@@ -203,7 +203,7 @@ the output file name e.g. ".xml".
 
 If specified allows control over when test discovery is performed.
 For a value of `POST_BUILD` (default) test discovery is performed at build time.
-For a a value of `PRE_TEST` test discovery is delayed until just prior to test
+For a value of `PRE_TEST` test discovery is delayed until just prior to test
 execution (useful e.g. in cross-compilation environments).
 ``DISCOVERY_MODE`` defaults to the value of the
 ``CMAKE_CATCH_DISCOVER_TESTS_DISCOVERY_MODE`` variable if it is not passed when

docs/matchers.md

@@ -286,7 +286,7 @@ comparable. (e.g. you may compare `std::vector<int>` to `std::array<char>`).
 `UnorderedRangeEquals` is similar to `RangeEquals`, but the order
 does not matter. For example "1, 2, 3" would match "3, 2, 1", but not
 "1, 1, 2, 3" As with `RangeEquals`, `UnorderedRangeEquals` compares
-the individual elements using using `operator==` by default.
+the individual elements using `operator==` by default.
 
 Both `RangeEquals` and `UnorderedRangeEquals` optionally accept a
 predicate which can be used to compare the containers element-wise.

docs/release-notes.md

@@ -381,7 +381,7 @@ v3 releases.
 * Added `STATIC_CHECK` macro, similar to `STATIC_REQUIRE` (#2318)
   * When deferred tu runtime, it behaves like `CHECK`, and not like `REQUIRE`.
 * You can have multiple tests with the same name, as long as other parts of the test identity differ (#1915, #1999, #2175)
-  * Test identity includes test's name, test's tags and and test's class name if applicable.
+  * Test identity includes test's name, test's tags and test's class name if applicable.
 * Added new warning, `UnmatchedTestSpec`, to error on test specs with no matching tests
 * The `-w`, `--warn` warning flags can now be provided multiple times to enable multiple warnings
 * The case-insensitive handling of tags is now more reliable and takes up less memory

docs/skipping-passing-failing.md

@@ -9,7 +9,7 @@ In some situations it may not be possible to meaningfully execute a test case,
 for example when the system under test is missing certain hardware capabilities.
 If the required conditions can only be determined at runtime, it often
 doesn't make sense to consider such a test case as either passed or failed,
-because it simply can not run at all.
+because it simply cannot run at all.
 
 To properly express such scenarios, Catch2 provides a way to explicitly
 _skip_ test cases, using the `SKIP` macro:

docs/test-cases-and-sections.md

@@ -231,7 +231,7 @@ TEMPLATE_TEST_CASE( "vectors can be sized and resized", "[vector][template]", in
 
 > [Introduced](https://github.com/catchorg/Catch2/issues/1468) in Catch2 2.6.0.
 
-_template-type1_ through _template-typen_ is list of template template
+_template-type1_ through _template-typen_ is list of template
 types which should be combined with each of _template-arg1_ through
  _template-argm_, resulting in _n * m_ test cases. Inside the test case,
 the resulting type is available under the name of `TestType`.

docs/tostring.md

@@ -75,7 +75,7 @@ CATCH_TRANSLATE_EXCEPTION( MyType const& ex ) {
 
 Enums that already have a `<<` overload for `std::ostream` will convert to strings as expected.
 If you only need to convert enums to strings for test reporting purposes you can provide a `StringMaker` specialisations as any other type.
-However, as a convenience, Catch provides the `REGISTER_ENUM` helper macro that will generate the `StringMaker` specialization for you with minimal code.
+However, as a convenience, Catch provides the `REGISTER_ENUM` helper macro that will generate the `StringMaker` specialisation for you with minimal code.
 Simply provide it the (qualified) enum name, followed by all the enum values, and you're done!
 
 E.g.

docs/why-catch.md

@@ -30,7 +30,7 @@ So what does Catch2 bring to the party that differentiates it from these? Apart
 * Output is through modular reporter objects. Basic textual and XML reporters are included. Custom reporters can easily be added.
 * JUnit xml output is supported for integration with third-party tools, such as CI servers.
 * A default main() function is provided, but you can supply your own for complete control (e.g. integration into your own test runner GUI).
-* A command line parser is provided and can still be used if you choose to provided your own main() function.
+* A command line parser is provided and can still be used if you choose to provide your own main() function.
 * Alternative assertion macro(s) report failures but don't abort the test case
 * Good set of facilities for floating point comparisons (`Catch::Approx` and full set of matchers)
 * Internal and friendly macros are isolated so name clashes can be managed