Test updates of CCCL (thrust, cub, libcudacxx) to 2.1.0.

[bdice]

This PR tests a rapids-cmake branch with CCCL (thrust, cub, libcudacxx) updated to 2.1.0. Do not merge this PR. The changes will be merged upstream in rapids-cmake after all libraries pass CI.

[bdice]

This PR is blocked until cudf is updated. rapidsai/cudf#13222

I think that since conda CI is passing, the wheel CI failures just indicate issues with compiling cudf itself.

[bdice]

This PR is ready to pass off to a cuSpatial C++ dev for completion. We are planning to ship CCCL 2.1.0 support (possibly CCCL 2.2.0) in RAPIDS 23.12. The corresponding rapids-cmake changes will be merged early in the development cycle for 23.12. We are aiming for the PRs to every RAPIDS library to be ready to merge changes needed for CCCL 2 support when 23.10 burndown begins and the 23.12 branch is created. The general readiness of RAPIDS libraries for this CCCL major version bump is being tracked here: rapidsai/rapids-cmake#399 (comment)

The major changes that are needed are to wrap device lambdas where the return type is needed on the host with cuda::proclaim_return_type<ReturnType>([...] __device__ (...){ ... });. This is most often needed for thrust::transform calls, or when constructing transform iterators, though other Thrust/CUB algorithms also have this requirement. Algorithms like thrust::for_each, however, do not require the return type to be known by the host, and therefore do not need it to be proclaimed. (Most of the time, I believe the difference has to do with whether the working memory or shared memory sizes of that algorithm depend on the return type.) I made a sample change that shows how to use cuda::proclaim_return_type<ReturnType> (note you must #include <cuda/functional> to use this feature). Please refer to rapidsai/cudf#13222 for more examples.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[bdice]

Closing in favor of #1314.