feat(cccl): integrate missing CCCL directories — python/, ci/, .agent/, docs/, test/

Sparse-checkout from NVIDIA/cccl main branch to complete cccl_upstream:

Added:
- python/cuda_cccl/ (226 files) — Python bindings for device-level algorithms
  Critical for muh toolchain: cuda.compute.reduce_into, scan, radix_sort, etc.
  Includes 204 .py files with full test coverage for all 27 algorithms
- ci/ (163 files) — Build/test infrastructure
  build_cub.sh, test_cub.sh, build_and_test_targets.sh, matrix.yaml
  Directly maps to our [INFRA-CI] and [INFRA-BUILD] items
- .agent/skills/ (7 files) — NVIDIA's own agent skills for CCCL
  cccl-style/SKILL.md, cccl-test/SKILL.md, sass-diff/SKILL.md
- docs/ (491 files) — Official CCCL documentation
  CI references, CMake guides, Python compute docs, libcudacxx PTX docs
- test/ (12 files) — Top-level integration tests (cuda_smoke, stdpar)
- Root configs: .clang-format, .clang-tidy, CONTRIBUTING.md, pyproject.toml
- CLAUDE.md symlink → AGENTS.md (NVIDIA's standard)

cccl_upstream now mirrors full NVIDIA/cccl structure:
  Before: 42M (cub + thrust + libcudacxx + cudax + c + examples + benchmarks)
  After:  53M (+python +ci +docs +.agent +test +configs)

This completes the CCCL base needed for:
- [muh-bench] items: ci/util/build_and_test_targets.sh for targeted builds
- [CCCL-verify] items: python/cuda_cccl/tests/ as reference implementations
- [CCCL-test] items: ci/test_cub.sh, ci/test_thrust.sh
- Agent workflow: .agent/skills/ for consistent style and test patterns
This commit is contained in:
muh-bot
2026-08-07 02:34:33 +00:00
parent 3f97dca7ad
commit 2a7ca101d7
908 changed files with 121615 additions and 0 deletions

View File

@@ -0,0 +1,14 @@
---
name: cccl-style
description: Use when editing or reviewing CCCL code for style conventions; read common CCCL guidance and the path-specific references named by this skill.
---
# CCCL Style
## Workflow
1. Read `references/common.md` for guidance that applies across CCCL.
2. For `libcudacxx/include/**/*`, also read `references/libcudacxx.md`.
3. For `cudax/include/**/*`, also read `references/libcudacxx.md`.
4. If no path-specific reference exists, follow nearby code and repository docs. Do not import rules from another subproject.
5. Apply each reference only to its stated scope. Rules for one CCCL subproject do not automatically apply to another.

View File

@@ -0,0 +1,70 @@
# Common CCCL Style Guidance
Apply this guidance across CCCL unless a path-specific style reference says otherwise.
## Naming Style
- Macros: macro style, e.g. `MY_MACRO`.
- Template parameters: PascalCase, e.g. `MyParameter`.
- All other symbols: snake style, e.g. `my_variable`. The one exception is the CUB public API, which uses PascalCase.
## Variables
- All variables that are not modified must use `const`. This includes variables initialized by casts (`static_cast`, `reinterpret_cast`, `bit_cast`), function return values, and loop-invariant computations.
- All variables that can be evaluated at compile-time must use `constexpr`.
- All `constexpr` variables at namespace/global scope must use `inline`, including variable templates.
- Consider using plural names for array, span, list, e.g. `int values[4]` instead of `int value[4]`.
- Use uniform initialization for class constructors (not enforced to builtin types) and compile-time conversions, e.g. `constexpr auto x = int{sizeof(float)};`.
## Headers
- Files must include all headers related to the symbols that they are using.
- Relying on transitive header inclusion is not allowed.
- Unneeded headers must be removed.
- All headers must have the correct license. This also applies to source files.
- All header inclusions must use the syntax `<header>`.
- Use forward declaration, namely `__fwd/header.h` or direct type declaration, when possible instead of including the implementation header.
- Headers should be the most precise available, e.g. `#include <cuda/std/__type_traits/is_array.h>`.
- Do not include headers in `cuda/std/__cccl/` directly; they are provided by `__config` or the prologue/epilogue mechanism.
## Functions
- Functions must be marked `_CCCL_HOST_API`, `_CCCL_DEVICE_API`, `_CCCL_HOST_DEVICE_API`, `_CCCL_TILE_API`, or `_CCCL_API`.
- Non-template, non-`constexpr` functions must use `inline`.
- Most functions with a non-void return type should use `[[nodiscard]]`; functions with known side effects may be exceptions.
- Functions that do not throw exceptions must use `noexcept`.
- Use `_CCCL_CONSTEVAL` when the function can only be evaluated at compile time.
- Use C++20 concept macros instead of SFINAE, e.g. `_CCCL_TEMPLATE(...)` and `_CCCL_REQUIRES(...)`.
## Function Calls And Types
- In headers, apply global qualification where the subproject requires it:
- libcudacxx and cudax require free function calls to be fully qualified from the global namespace, e.g. `::cuda::ceil_div(...)`.
- CUB applies this rule only to calls to symbols under the `::cuda` namespace hierarchy; otherwise follow existing CUB qualification style.
- Thrust uses leading `::` for many symbols under the `::cuda` namespace hierarchy, but relies on ADL in many places and the blanket free-function qualification rule does not apply to those calls.
- For covered calls, this includes calls to functions defined in the same namespace, e.g. inside `cuda::`, call `::cuda::ceil_div(...)`, not `ceil_div(...)`. This does not apply to (static) member functions of classes. The only exceptions for covered calls are functions that are supposed to be found through argument-dependent lookup (ADL), such as `::cuda::std::swap` and `::cuda::std::get`. Those functions can be called unqualified with a preceding `using ::cuda::std::get;`.
- This global-qualification rule does not apply to source files such as tests and benchmarks.
- In headers, apply type-name qualification where the subproject requires it:
- libcudacxx and cudax require type names to be fully qualified except when they are already declared in the current namespace or an enclosing one. Outside those namespaces, fully qualify `cuda::std` and standard integer type aliases such as `::cuda::std::size_t`.
- CUB applies this rule only to type names under the `::cuda` namespace hierarchy. Do not apply the libcudacxx/cudax blanket type-qualification rule to CUB namespaces or `detail` namespaces.
- Thrust does not apply the libcudacxx/cudax blanket type-qualification rule. It uses leading `::` for many `::cuda` and `::cuda::std` type names, but also uses Thrust namespace patterns; follow neighboring Thrust code.
- A local `using` declaration, e.g. `using ::cuda::std::size_t;`, is acceptable to avoid repetition within a function body.
- Static member functions of a class template inherit the class's namespace.
## Comments
- Commented code without a description is not allowed.
## General Guidelines
- The code must reuse `cuda/` or `cuda/std` functionalities as much as possible, including macros.
- Try to use modern C++ as much as possible. The repository supports C++17 but many more recent functionalities have been backported with functions and macros.
## Prevent Compiler Errors And Improve Compatibility
- Remove unused code, variables, functions, types, template parameters, headers, etc.
- Variables that are unsigned, or that can become unsigned after template instantiation, must not check for negative values directly. Use `cuda::std::is_unsigned_v<T> ? false : (var < 0)` instead.
## Compiler Compatibility
- Protect host-only code with `#if !_CCCL_COMPILER(NVRTC)`.

View File

@@ -0,0 +1,55 @@
# libcudacxx Style Guidance
Use this reference for `libcudacxx/include/**/*` and `cudax/include/**/*`.
## Naming Style
All non-public symbols must be C++ reserved identifiers:
- `_` for macros and template parameters, e.g. `_MY_MACRO`, `_MyParameter`.
- `__` for all other symbols, e.g. `__my_variable`.
- Never use reserved keywords, such as `__in`, `__out`, or `__inout` as variables, parameters, or function names.
- Avoid single-letter template parameter names. Wrong: `_T`; correct: `_Tp`.
## Class / Struct
- Data member names have postfix `_`, e.g. `class __myclass { int __data_; };`.
- Constructor parameter names should match class/struct data member names without the postfix `_`, e.g. `class __myclass { __myclass(int __data) : __data_(__data) {} };`.
## Functions
- Use `constexpr` for functions that do not depend on run-time features, such as pointers.
- If the return type is not explicit (`auto`), then a trailing return type is strongly preferred.
## Headers
- Use the correct license:
- `libcudacxx/include/cuda/std` files ported from LLVM libc++ use the LLVM license.
- `libcudacxx/include/cuda/` files use Apache License v2.0 with LLVM Exceptions.
- Headers use include guards with names derived from the uppercase full path and closing `#endif` comments repeating the guard name.
- Right after the include guard, include:
```cpp
#include <cuda/std/detail/__config>
#if defined(_CCCL_IMPLICIT_SYSTEM_HEADER_GCC)
# pragma GCC system_header
#elif defined(_CCCL_IMPLICIT_SYSTEM_HEADER_CLANG)
# pragma clang system_header
#elif defined(_CCCL_IMPLICIT_SYSTEM_HEADER_MSVC)
# pragma system_header
#endif // no system header
```
- The last included header before code must be `<cuda/std/__cccl/prologue.h>`, and `<cuda/std/__cccl/epilogue.h>` must appear at the end of the file.
## Comments
- Use Doxygen-style `//! @brief` comments.
- Documented functions must include `//! @brief`, `//! @param[in/out/in,out]` for every parameter, and `//! @return` for non-void functions.
- The `@brief/@param/@return` description must accurately reflect the current functionality of the function.
## Compiler Compatibility
- Do not use lambda expressions in device-only or host-device code.
- Do not rely on deduction guides for initialization; use explicit template arguments instead.