-
Notifications
You must be signed in to change notification settings - Fork 907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add clang-tidy for automatic linting #584
Comments
Duplicate #479 |
@jrhemstad @harrism Now that we've merged #6695 I think there is interest in enabling clang-tidy on the libcudf code base so I'm reopening this issue. If we'd prefer to consolidate discussion on #479 we can close this again and reopen that, but offhand it seems like #479 grew into a much more involved discussion about defining a style guide and enabling clang-tidy with some minimal configuration seems like a simpler goal to start with. |
Agree! @teju85 is interested in having a shared cross-rapids clang-tidy config. This makes sense as we have more or less converged on a shared RAPIDS clang-format config. |
Thank you Mark for adding me to this discussion. Yes, I'm certainly interested in a more uniform tidy config across RAPIDS! BTW, we already have clang-tidy running as part of CI for cuml for almost a year now (though not super stringent, yet). cuML CI is here. However, when it was introduced, we were at clang v8.0.1 which wasn't particularly great with .cu/.cuh files! So, the tidy wrapper script had to take in a bunch of hacks :(. If someone can pick up this flow, improve and generalize it for RAPIDS-wide usage, that'd be awesome. Finally, I'm not particularly attached to these scripts or a particular style (eg: google, cpp-core, etc) and will happily accept if there's a better solution for RAPIDS. However, I'd like for atleast all the key devs to be involved and their requirements heard before finalizing on a tidy style guide. Because in my personal opinion, tidying has a bigger benefit in terms of code uniformity and readability, especially for folks working across RAPIDS projects. |
JFYI, there's a similar wrapper script in raft, but has not yet been added to CI workflow. |
@codereport would #10064 close this? We can always add more rules a la #10174 later as we decide that they are useful. Is there a reason we closed those PRs, or are they worth someone picking up? |
As a first step I would prioritize finding a way to run clang-tidy in CI. PRs that fix clang-tidy errors are nice, but we inevitably accumulate more without CI checking for us. |
Based on what I found in #581, I think getting this working is going to first involve expending significant effort in ensuring that all of our dependencies compile with clang to start with. I know that cuML is already running clang-tidy, but they also have significant logic built around wrapping the clang-tidy invocation so I assume that they are also doing some preprocessing to only lint the files that they can compile. I could be wrong, though, and perhaps there's a simpler path here. EDIT: It looks like cuML is skipping cu files altogether. |
Clang can compile .cu files. Otherwise clangd intellisense wouldn't work. |
Clang can compile cu files, but there are various headers in libcu++/thrust/cuco/etc that compile under nvcc but not clang (for various reasons). I don't use Intellisense so I can't say exactly what is currently working and what isn't, perhaps it just skips TUs that don't compile. |
This changeset is large, but it's not very substantial. It's all the automated fixes produced by clang-tidy using our script. The bulk of the changes are either adding `[[nodiscard]]` to many functions or changing const ref args to pass by value and then move in cases where the parameter is only used to set a value. There are also some places where clang-tidy preferred either more or less namespacing of objects depending on the current namespace. The goal is to enable clang-tidy in CI, which we made progress towards in #9860 but stalled in #10064. This PR contains the first set of changes that will required for such a check to pass. I've marked this PR as breaking because some of the functions now marked as `[[nodiscard]]` are public APIs, so if consumers were ignoring the return values they will now see warnings, and if they are compiling with warnings as errors then the builds will break. Contributes to #584 Authors: - Vyas Ramasubramani (https://github.com/vyasr) Approvers: - Bradley Dice (https://github.com/bdice) - Nghia Truong (https://github.com/ttnghia) URL: #15894
This PR adds clang-tidy checks to our CI. clang-tidy will be run in nightly CI via CMake. For now, only the parts of the code base that were already made compliant in the PRs leading up to this have been enabled, namely cudf source and test cpp files. Over time we can add more files like benchmarks and examples, add or subtract more rules, or enable linting of cu files (see https://gitlab.kitware.com/cmake/cmake/-/issues/25399). This PR is intended to be the starting point enabling systematic linting, at which point everything else should be significantly easier. Resolves #584 Authors: - Vyas Ramasubramani (https://github.com/vyasr) Approvers: - Kyle Edwards (https://github.com/KyleFromNVIDIA) - Bradley Dice (https://github.com/bdice) URL: #16958
Feature request
In similar spirit of #117, would be good to start using
clang-tidy
as a linter on the codebase to catch some errors, style violations, etc.Arrow's setup would be a good place to start, which includes a CMake target to run the tool and a custom version of
run-clang-tidy
which supports ignoring some files.The text was updated successfully, but these errors were encountered: