feat(mapper): add CUDA support#108
Open
danielbrodie wants to merge 7 commits into
Open
Conversation
Recognize CUDA .cu/.cuh sources across standalone main() files, CMake add_executable/add_library (including the legacy FindCUDA cuda_add_executable/cuda_add_library commands), and autotools targets. Repositories containing CUDA sources are detected as cuda projects, and CUDA targets carry the concurrency trust boundary. Map source files that no build target owns into bounded, per-directory source groups so loose C/C++/CUDA code is no longer skipped, and map CMakeLists.txt, CMakePresets.json, and configure.ac as config features. Emit conservative C/C++/CUDA validation commands only when the project declares them: a root Makefile check/test target, or a CMakePresets.json build workflow. Otherwise no validation command is set.
When a reviewed feature owns CUDA .cu/.cuh sources, add a CUDA hazard checklist to the review prompt (default mode only) and the fix prompt: kernel races and synchronization, unchecked CUDA runtime calls, host/device pointer confusion, memory-access hazards, and device-memory leaks. Detection is by file extension, so mixed host/device targets are covered. Findings map to the existing categories. Deslopify mode and the prompt-file override are unaffected, and non-CUDA prompts are unchanged.
Update the feature-mapping and code-review docs, the README mapping list, and the changelog for CUDA source mapping, validation command defaults, and CUDA-aware review and fix guidance.
|
Codex review: needs maintainer review before merge. Latest ClawSweeper review: 2026-05-22 23:14 UTC / May 22, 2026, 7:14 PM ET. Workflow note: Future ClawSweeper reviews update this same comment in place. How this review workflow works
Summary Reproducibility: not applicable. as a bug reproduction: this is a feature PR. Source inspection confirms current main lacks .cu/.cuh mapping and CUDA prompt guidance, and the PR body includes copied CLI output from a CUDA demo run. PR rating Rank-up moves:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. Real behavior proof Risk before merge
Maintainer options:
Next step before merge Security Review detailsBest possible solution: Land the PR after maintainers explicitly accept or narrow the declared C/C++ validation defaults, preserving the all-owned-source CUDA tagging and narrowed Makefile behavior. Do we have a high-confidence way to reproduce the issue? Not applicable as a bug reproduction: this is a feature PR. Source inspection confirms current main lacks .cu/.cuh mapping and CUDA prompt guidance, and the PR body includes copied CLI output from a CUDA demo run. Is this the best way to solve the issue? Yes, with one maintainer policy decision. The implementation follows the existing mapper and prompt patterns, and the latest commits fix the mixed-target metadata path and narrow Makefile validation to declared targets. Label changes:
Label justifications:
What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 857d854ac8d0. |
clawsweeper
Bot
added
rating: 🦪 silver shellfish
|
ClawSweeper PR egg ✨ Hatched: 🥚 common Sunspot Lint Imp Hatch commandComment Hatchability rules:
Rarity: 🥚 common. What is this egg doing here?
|
CMake and autotools build targets previously took their language tag from the picked entry path alone. For a mixed CMake target like `add_executable(app main.cpp kernel.cu)`, `pickExecutableEntry` selects the host `main.cpp`, so the feature was tagged `cpp` and missed the `concurrency` trust boundary even though the target owns CUDA code. Add a `targetLanguageTag(entryPath, sourcePaths)` helper that returns `cuda` when any owned source is `.cu` or `.cuh`, otherwise the entry's own tag, and apply it at the five multi-source seed sites: `cmake-bin`, `cmake-lib`, `cmake-test`, `autotools-bin`, and `autotools-lib`. The standalone `c-main` site keeps the per-file tag because it has one source by definition. The new regression test covers the mixed `.cpp` + `.cu` CMake target case where the entry is the host source.
The previous default emitted `typecheck: "make"` for any root
`Makefile`, which would run the project's default Makefile target
during `clawpatch fix` validation. That broadened local code execution
to any Makefile-bearing C/C++ repository, beyond what the project
explicitly declared.
Narrow the default so the Makefile path only emits `test: "make check"`
or `test: "make test"` when the Makefile declares those targets, and
otherwise returns no commands. This aligns the implementation with the
`docs/feature-mapping.md` description ("only when the project declares
them: a root Makefile check/test target, or a CMakePresets.json build
workflow") and the matching `CHANGELOG.md` entry, both of which already
say "declared" rather than "any".
The two existing Makefile validation tests are renamed and updated to
match the narrowed shape.
Author
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
proof: sufficient
Defers routine dev guidance to AGENTS.md; adds only what's not there: non-default branch/remote setup (cuda branch on fork remote), dogfood awareness (claude is itself a clawpatch provider), .clawpatch/ state dir, CLAWPATCH_CODEX_SANDBOX env var, dist/ build-output guidance. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…xed-language projects When a project mixes C/C++/CUDA sources with another language whose defaults sit higher in the language priority list (for example a Python repo with CUDA kernels), `detectCommands` settled on the higher-priority defaults and `validationCommandsForFeature` then ran them against every feature, including the ones tagged `cuda`, `cpp`, or `c`. The `fix` flow used those same commands to validate CUDA repairs, which is wrong tooling. Capture a second `nativeCommands` set on the project record whenever C/C++/CUDA sources are present, populated from the existing `cOrCppDefaultCommands` helper (a Makefile `check`/`test` target, or a `CMakePresets.json` build/test workflow). It is left null when the primary commands already come from that path, and stays null when no native commands can be derived. `validationCommandsForFeature` now takes the optional native set and switches to it for features tagged `c`, `cpp`, or `cuda`. Features without those tags continue to run the primary commands unchanged. Schema additions on `projectRecordSchema.detected` and `configSchema` are nullable and default to null, so existing `.clawpatch/config.json` files load without migration.
Author
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
.cu/.cuhsources across standalonemain()files, CMakeadd_executable/add_library(including the legacyFindCUDAcuda_add_executable/cuda_add_librarycommands), and autotools targets. Repositories containing CUDA sources are detected ascudaprojects.CMakeLists.txt,CMakePresets.json, andconfigure.acas config features.Makefilecheck/testtarget, or aCMakePresets.jsonbuild workflow. No build command is invented.c,cpp, orcudaeven when another language's defaults win the project's language priority (for example a Python repository with CUDA kernels would otherwise runpytestagainst CUDA features). The native command set is captured alongside the primary set onprojectRecordSchema.detected.nativeCommandsandconfigSchema.nativeCommands; both fields are nullable and default to null, so existing.clawpatch/config.jsonfiles load without migration..cppand.cusources is taggedcudawith theconcurrencytrust boundary, even when its entry point is the host.cpp.concurrencytrust boundary..cu/.cuhsources, add a CUDA hazard checklist to the review prompt (default mode only) and the fix prompt: kernel races and synchronization, unchecked CUDA runtime calls, host/device pointer confusion, memory-access hazards, and device-memory leaks. Detection is by file extension so mixed host/device targets are covered.categoryenum; no schema change. Deslopify mode and--prompt-fileare unaffected, and non-CUDA prompts are unchanged.README.md,docs/feature-mapping.md, anddocs/code-review.md; add changelog entries under0.4.1 - Unreleased.Why
clawpatch's C/C++ mapper handles generic project shapes, and CUDA was not covered. This change maps CUDA projects and makes the review aware of CUDA-specific bug classes. The mapper updates follow the existing C/C++ patterns; the review prompt change reuses the
reviewModeInstructionsinjection style with extension-based triggering so mixed host/device targets are caught.Validation
pnpm typecheckpnpm lintpnpm format:checkpnpm test(744 passed, 1 skipped)pnpm buildpnpm pack:smokeDemonstration
To make the CUDA-aware mapping and review inspectable, here is the locally-built
clawpatchrun against a small demo CUDA project (oneCMakeLists.txtplussrc/main.cu,src/kernels.cu,src/kernels.cuh). The CMake target lists.cuand.cuhsources, and the demo carries deliberate textbook CUDA hazards.clawpatch mapandclawpatch review --provider codexoutputThe four findings produced by codex on the CUDA binary feature, excerpted from
clawpatch report:category: bug,confidence: high, evidencesrc/main.cu:30-32andsrc/kernels.cu:3-5. "Kernel writes past the end for non-multiple block sizes. The launch rounds block count up for any n that is not an exact multiple of 256, but the kernel writesy[i]without checkingi < n."category: bug,confidence: high, evidencesrc/main.cu:24-34. "CUDA runtime failures are ignored.cudaMalloc,cudaMemcpy, and the kernel launch are all used without checking return status or launch errors. Check every CUDA runtime call, checkcudaGetLastError()immediately after the kernel launch, and callcudaDeviceSynchronize()before consuming results."category: bug,confidence: high, evidencesrc/main.cu:12-17andsrc/main.cu:24-31. "User supplied n is not validated before size calculations.std::atoisilently accepts non-numeric input as 0 and negative values as negative integers."category: performance,confidence: high, evidencesrc/main.cu:22-25andsrc/main.cu:40-42. "Device allocations are never freed.d_xandd_yare allocated withcudaMallocbut there are no matchingcudaFreecalls before the program returns."Each finding maps to the existing
categoryenum (bug,build-release,performance), and the binary feature carries thecudatag with theconcurrencytrust boundary because its CMake target owns.cuand.cuhsources.