Documentation typos (#2302)

* add segmented [radix] sort tests for 64-bit indices

* Add test for device segmented sort pairs with 64-bit indices

* Add a macro guard to protect tests that are not supported yet

* Fix documentation typos

* Remove unrelated files

docs/cpp.rst

@@ -43,7 +43,7 @@ be better served by unifying them into a single repository.
   OpenMP).
 
 - `Cuda Experimental <https://nvidia.github.io/cccl/cudax/>`__
-  is a library of exerimental features that are still in the design process.
+  is a library of experimental features that are still in the design process.
 
 The main goal of the CCCL C++ libraries is to fill a similar role that the
 Standard C++ Library fills for Standard C++: provide general-purpose,

docs/cub/benchmarking.rst

@@ -1,7 +1,7 @@
 CUB Benchmarks
 *************************************
 
-This file contains instrutions on how to run all CUB benchmarks using CUB tuning infrastructure.
+This file contains instructions on how to run all CUB benchmarks using CUB tuning infrastructure.
 
 .. code-block:: bash
 

docs/cub/developer_overview.rst

@@ -726,7 +726,7 @@ To satisfy (1), the visibility of ``thrust::cuda_cub::launcher::triple_chevron``
 
 To satisfy (2), instead of annotating kernels as ``__global__`` we annotate them as
 ``CUB_DETAIL_KERNEL_ATTRIBUTES``. Apart from annotating a kernel as global function, the macro also
-contains an attribute to set the visibility to bidden.
+contains an attribute to set the visibility to hidden.
 
 To satisfy (3), CUB symbols are placed inside an inline namespace containing the set of
 GPU architectures for which the TU is being compiled.

docs/cub/test_overview.rst

@@ -95,7 +95,7 @@ but are modified to provide more stable behavior in some testing edge cases.
     unless the test code is being used for documentation examples.
 
 Similarly, any thrust algorithms that executed on the device must be invoked with the
-`c2h::device_policy`` execution policy (not shown here) to support the same edge cases.
+`c2h::device_policy` execution policy (not shown here) to support the same edge cases.
 The memory is filled with random data in (2).
 
 Generator ``c2h::gen`` takes at least two parameters.
@@ -327,4 +327,4 @@ Overall, the test will produce two executables.
 Each of these executables is going to generate ``2`` input problem sizes.
 For each problem size, ``3`` random vectors are generated.
 As a result, we have ``12`` different tests.
-The code also demonstrates the syntax and usage of ``c2h::device_policy`` with a Thrust alorithm.
+The code also demonstrates the syntax and usage of ``c2h::device_policy`` with a Thrust algorithm.

docs/cub/tuning.rst

@@ -37,7 +37,7 @@ Contributing Benchmarks
 
 There are a few constraints on benchmarks. First of all, all benchmarks in a single
 file should share type axes. Only alphabetical characters, numbers and underscore are allowed in the
-benchmark name.  The name of the file is represets the name of the algorithm.
+benchmark name.  The name of the file represents the name of the algorithm.
 For instance, the :code:`benchmarks/bench/radix_sort/keys.cu` file name is going to be transformed
 into :code:`cub.bench.radix_sort.keys` that's further used in the infrastructure.