Skip to content
cccskills
FreePublished on GitHub

clang-tidy-check

Run clang-tidy static analysis, which checks code without executing it, on added or modified BE and Cloud C++ files. Focus diagnostics on changed lines, investigate bug, performance, and readability warnings, and verify fixes with another check.

OriginalShow the original description

Run clang-tidy on newly added/modified BE C++ code

See how to install

Good for

  • Check changed C++ code before committing
  • Investigate clang-tidy warnings reported by CI
  • Review changes against a specific branch
  • Analyze Cloud files with the matching compilation database

Files included (1)

  • SKILL.md5.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

What I do

Run clang-tidy static analysis on newly added or modified C++ files in the BE and Cloud modules, using the project's .clang-tidy configuration. The script parses git diff to identify changed line ranges and filters clang-tidy output to diagnostics on those lines where possible, reducing noise from pre-existing code. Diagnostics from included headers that were not part of the diff are filtered out, though some edge cases may still appear.

When to use me

  • After building BE, before committing C++ code changes
  • When CI reports clang-tidy warnings on your PR
  • When you want to proactively check new code for common bugs and style issues

Prerequisites

  1. The relevant module must be built first — clang-tidy needs compile_commands.json generated during the CMake build. For BE files, build BE; for Cloud files, build Cloud.
  2. clang-tidy must be installed — the project uses clang-tidy from the LDB toolchain.

Procedure

Step 1: Build the relevant module (if not already done)

For BE files:

./build.sh --be -j${DORIS_PARALLELISM}

This generates compile_commands.json in be/build_Release/ or be/build_ASAN/.

For Cloud files:

./build.sh --cloud -j${DORIS_PARALLELISM}

This generates compile_commands.json in cloud/build_Release/ or cloud/build_ASAN/.

Note: A single compilation database typically covers only one module (BE or Cloud). If your changes span both modules, you may need to run clang-tidy twice with different --build-dir values.

Step 2: Run clang-tidy on changed files

build-support/run-clang-tidy.sh

By default, this script:

  • Detects changed C++ files via git diff (uncommitted changes + staged changes)
  • Automatically finds compile_commands.json from the latest BE build
  • Runs clang-tidy using the .clang-tidy config
  • Skips files in excluded directories (third-party, generated code)
  • Reports warnings grouped by file

Options:

# Compare against a specific branch (e.g., for PR review)
build-support/run-clang-tidy.sh --base origin/master

# Check specific files (all lines, no line-level filtering)
build-support/run-clang-tidy.sh --files be/src/vec/functions/my_new_func.cpp

# Report ALL warnings in changed files (no line filtering)
build-support/run-clang-tidy.sh --full

# Specify build directory explicitly (required for Cloud if BE build dir was auto-detected)
build-support/run-clang-tidy.sh --build-dir be/build_ASAN

# Check Cloud files with Cloud compilation database
build-support/run-clang-tidy.sh --build-dir cloud/build_ASAN

# Apply auto-fixes where possible (note: fixes may apply beyond changed lines)
build-support/run-clang-tidy.sh --fix

Important: By default, only warnings on changed lines are reported (diagnostics from headers not in the diff are filtered out). This prevents the agent from "fixing" unrelated pre-existing warnings in large files. Use --full to see all warnings if needed.

Step 3: Interpret and fix warnings

clang-tidy output looks like:

be/src/vec/functions/foo.cpp:42:5: warning: use auto when initializing with a cast [modernize-use-auto]
be/src/vec/functions/foo.cpp:55:1: warning: function 'process' exceeds recommended size [readability-function-size]

Fix approach:

  1. Fix all warnings that represent real issues (bugs, performance, readability)
  2. For false positives or intentional patterns, add // NOLINT(check-name) with a brief justification
  3. Report any warnings you cannot reasonably fix

Step 4: Verify

Re-run the script to confirm all warnings are resolved:

build-support/run-clang-tidy.sh

Enabled Checks (from .clang-tidy)

CategoryExamples
clang-diagnostic-*Compiler diagnostics
clang-analyzer-*Static analysis (null deref, use-after-free, etc.)
bugprone-*Use-after-move, redundant branch condition, unused RAII
modernize-*Auto, range-for, nullptr (excludes trailing return, nodiscard)
readability-*Function size (≤80 lines), cognitive complexity (≤50)
performance-*String find, inefficient algorithm, move-const-arg
misc-redundant-expressionRedundant expressions

Excluded Directories

Files in these paths are automatically skipped:

  • be/src/apache-orc/, be/src/clucene/, be/src/gutil/
  • be/src/glibc-compatibility/
  • contrib/ (all third-party code)
  • Generated code directories

NOLINT Usage

When a clang-tidy warning cannot be fixed, suppress it with a comment:

// Good: specific check name + reason
int x = (int)y; // NOLINT(modernize-use-auto): explicit cast for clarity

// Bad: blanket suppression without reason
int x = (int)y; // NOLINT

Troubleshooting

ProblemSolution
compile_commands.json not foundBuild BE first: ./build.sh --be -j${DORIS_PARALLELISM}
clang-tidy not foundInstall via LDB toolchain or apt install clang-tidy-16
Too many warnings on old codeUse --base to diff against a branch, ensuring only your changes are checked
Warning in header included by your fileOnly fix if the header is also in your changeset; otherwise note it in your report

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

be-code-style

FreeSummary

Format C++ code in the BE and Cloud modules using the project's clang-format v16 rules. Use the provided scripts to fix formatting or check for violations without changing files, then review the resulting differences before committing.

  • Format BE or Cloud C++ code before committing
  • Fix formatting failures reported by CI
  • Check formatting without modifying files
apache/doris16.1KUpdated Oct 18, 2026

code-review

FreeSummary

Review Doris code changes using project-specific checklists for data correctness, concurrency, memory safety, compatibility, performance, and tests. Trace related code paths and explain findings with concrete failure scenarios, using query plan trees when reviewing optimizer behavior.

  • Review newly completed Doris code changes
  • Check concurrency and memory management in related code paths
  • Assess compatibility and test coverage before merging
apache/doris16.1KUpdated Oct 18, 2026

Prepare a clean Doris package and run Docker regression tests, which check whether changes break existing behavior. Restore configuration and startup files from Git, build the test image, and investigate failures using configuration checks and runtime logs.

  • Run Docker regression tests before submitting Doris changes
  • Test without local configuration changes affecting results
  • Investigate missing test suites or startup failures
apache/doris16.1KUpdated Oct 18, 2026

fe-code-style

FreeSummary

Diagnoses and fixes Java style violations in the FE module using Checkstyle, a tool that checks coding rules. It interprets errors, applies the project's formatting and import restrictions, and reruns checks to verify fixes.

  • Checking FE Java changes before committing
  • Fixing build failures caused by Checkstyle violations
  • Understanding project-specific style and import rules
apache/doris16.1KUpdated Oct 18, 2026

See all skills by apache

Report a problem with this skill