Fix CCCL/Jitify compatibility issues for NVRTC compilation

[a-hirota]

Description

This PR fixes build failures caused by type redeclaration conflicts between CCCL 3.0.2 and
Jitify when compiling with NVRTC.

Problem

When building cuDF with ./build.sh, the JIT preprocessing step fails with errors like:
cuda/std/cstdint(43): error: invalid redeclaration of type name "int_fast16_t"
cuda/std/cstdint(60): error: invalid redeclaration of type name "intptr_t"
limits(149): error: invalid narrowing conversion from "int" to "char"

Root Cause

1. CCCL's NVRTC-specific stdint type definitions conflict with system stdint.h when both are
   included
2. Jitify's numeric_limits template fails to compile due to narrowing conversion when CHAR_MAX
   is an int value

Solution

This PR adds two patches that are automatically applied during the CMake build process:

1. CCCL Patch (cccl_jitify_compatibility.patch)

• Guards type definitions with #ifndef _STDINT_H to prevent redeclaration when stdint.h is
  already included
• Adds explicit casts to CHAR_MIN/MAX macros to avoid narrowing conversions

2. Jitify Patch (jitify_char_limits.patch)

• Adds explicit casts in numeric_limits template instantiation

Testing

• Successfully builds with ./build.sh on Ubuntu with CUDA 13.0
• JIT preprocessing (make jitify_preprocess_run) completes without errors
• Patches are applied automatically during the build process

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[Copilot]

Pull Request Overview

This PR fixes NVRTC compilation failures by resolving type redeclaration conflicts between CCCL 3.0.2 and Jitify through automated patch application during the CMake build process.

• Adds guards to prevent stdint type redeclarations in CCCL when system stdint.h is included
• Fixes narrowing conversion errors in numeric_limits template instantiations
• Implements automatic patch application through CMake configuration

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
cpp/cmake/thirdparty/patches/jitify_override.json	Configuration to apply Jitify patch for char limits fix
cpp/cmake/thirdparty/patches/jitify_char_limits.patch	Patch file adding explicit casts to fix narrowing conversions
cpp/cmake/thirdparty/patches/cccl_override.json	Configuration to apply CCCL compatibility patch
cpp/cmake/thirdparty/patches/cccl_jitify_compatibility.patch	Patch file adding include guards and fixing char limits
cpp/cmake/thirdparty/get_jitify.cmake	Updated to apply Jitify patch during build
cpp/cmake/thirdparty/get_cccl.cmake	Updated to apply CCCL patch during build

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The || true clause will suppress all git apply failures, including legitimate patch application errors. This could mask real issues when the patch fails to apply correctly, leading to silent build failures later.

Suggested change

	PATCH_COMMAND git apply --reject --whitespace=fix ${CMAKE_CURRENT_LIST_DIR}/patches/jitify_char_limits.patch || true
	PATCH_COMMAND git apply --reject --whitespace=fix ${CMAKE_CURRENT_LIST_DIR}/patches/jitify_char_limits.patch

[Copilot]

The macro _STDINT_H is implementation-specific and may not be consistent across all compilers and standard libraries. Consider using a more portable approach like checking for specific types or using a project-specific guard macro.

[Copilot]

This duplicates the same implementation-specific _STDINT_H guard used for type definitions. The inconsistency in approach (guarding types and macros separately with the same condition) could lead to maintenance issues.

[a-hirota]

Response to GitHub Copilot Review Comments

GitHub Copilot raised two valid concerns about this implementation. Here's my analysis and rationale for the current approach:

1. Regarding || true in Jitify patch command

Copilot's concern: The || true suppresses all git apply failures, potentially masking legitimate patch application errors.

Current rationale: The || true is necessary because:

• The patch may be applied multiple times during incremental builds or when switching between clean/dirty build states
• Without it, builds fail when the patch is already applied
• The CCCL patch uses rapids-cmake's override system which handles idempotency properly
• For Jitify, we use CMake's PATCH_COMMAND which doesn't have the same idempotency infrastructure

Alternative considered: Adding a check like git apply --check before applying, but this adds complexity for a temporary fix.

2. Regarding _STDINT_H macro portability

Copilot's concern: The _STDINT_H macro is implementation-specific and may not be consistent across all compilers.

Current rationale:

• _STDINT_H is used by glibc (Linux), which is cuDF's primary target platform
• This code only executes in NVRTC context with controlled environment
• The fix is temporary until upstream CCCL/Jitify resolve the compatibility issue

Future improvement: For broader portability, we could check multiple guards:

#if !defined(_STDINT_H) && !defined(__STDINT_H) && !defined(_STDINT)

Summary

Both concerns represent valid engineering trade-offs. The current implementation prioritizes:
1. Build reliability over perfect error reporting (via || true)
2. Target platform support over universal portability (via _STDINT_H)

These are temporary patches until upstream fixes are available. The build successfully completes with these changes on Ubuntu/CUDA 13.0.

Happy to discuss alternative approaches or make improvements based on maintainer preferences.

[a-hirota]

Update: Force-pushed to revert to working version (commit e1cda95ac7) due to build failures when addressing Copilot feedback.

[davidwendt]

CCCL does not generally want us to add patching like this.
Could you open an issue or PR in the CCCL repo and/or Jitify to fix this there instead?

[a-hirota]

Thank you for your feedback. This PR applies temporary patches on the cuDF side to work around a build failure caused by type redeclaration conflicts between CCCL 3.0.2 and Jitify when compiling with NVRTC. I understand that CCCL generally prefers not to apply such patches downstream.

I will open an issue and/or pull request in the NVIDIA/cccl repository and in Jitify to address the underlying problem upstream. In the meantime, could you advise on the best approach to keep cuDF building until the upstream changes are merged? Once I create the issues/PRs, I will share the links here for your review.

Thank you again for your guidance.

[vyasr]

@lamarrr might be the best person to review this right now since he's done the jitify updates recently including similar compatibility issues like NVIDIA/jitify#147.

[lamarrr]

Thanks for the detailed report and patch @a-hirota. As @davidwendt mentioned, we generally avoid making one-off patches. Can you please submit a PR to both JITIFY and CCCL? If not, we can help make the PRs.
Are these actually errors or warnings being raised as errors due to a Werror flag?

[a-hirota]

Thanks @lamarrr! These are definitely actual compilation errors, not warnings. The issue is quite extensive - here's a sample of the errors:

cuda/std/cstdint(43): error: invalid redeclaration of type name "int_fast16_t"
cuda/std/cstdint(47): error: invalid redeclaration of type name "uint_fast16_t"
cuda/std/cstdint(60): error: invalid redeclaration of type name "intptr_t"
limits(149): error: invalid narrowing conversion from "int" to "char"
cuda/std/__cmath/isnan.h(48): error: expected an identifier

The problem affects multiple kernel files and causes cascading errors throughout CCCL's math functions (isnan, isinf, etc.) and NVIDIA-specific floating-point types. The compilation hits the 100-error limit, so there are likely even more issues.
If you could help create the PRs for both Jitify and CCCL, that would be incredibly helpful and much faster than me trying to tackle this complex issue. The scope is quite broad and would benefit from your expertise!
Thank you so much for offering to help!

[lamarrr]

I don't think CCCL is the right place to have these changes.
The casts on the macros are not necessary, the limits are declared in other standard library implementations similarly. I think the cast in the numeric_limits header would be sufficient.
Regarding duplicate declarations, it would be best to handle them within JITIFY, rather than within the actual system standard library.

[a-hirota]

Hi @lamarrr,

Thank you for reviewing my PR and for opening NVIDIA/jitify#150 to address the numeric_limits<char> narrowing issue. As you pointed out, adding one‑off patches in cuDF—especially in CCCL—may not be ideal:contentReference[oaicite:4]{index=4}. My current PR includes a temporary patch for CCCL and a patch for Jitify to keep cuDF building until upstream fixes are available.

Since there is now an upstream fix for Jitify and CCCL does not want downstream patches:contentReference[oaicite:5]{index=5}, I'm thinking about closing this PR rather than keeping a temporary CCCL patch in cuDF. Do you think it makes sense to close it and wait for the Jitify fix to land, or should we keep this open (perhaps removing the CCCL part) until the upstream changes are merged and cuDF is updated?

I’d appreciate your guidance on the best course of action.

Thanks again!