Code pull request (동료/coderabbit)전에 실행하는 명령어.
두번정도 돌려야 완성됨
# Fix Linter Diagnostics
Review and address relevant clang-tidy diagnostics for recently edited files, but keep the
lint scope, binary selection, and verification loop aligned with the repository scripts.
## Workflow
1. Run Scripts/clangTidy.sh from the repository root with its default arguments.
– Let the script determine the relevant recently edited files and lint scope.
– Use shell commands only through the terminal tool.
– Treat this script as the source of truth for selected files, compile database, header filter, .clang-tidy config,
CUDA arguments, and resolved tool binaries.
2. Inspect the clang-tidy-fixes.yaml file written under the build directory selected by Scripts/clangTidy.sh.
– Treat this file as the canonical summary of the identified diagnostics.
– The wrapper currently chooses the newest available compile_commands.json under build/; do not assume the path
is build/Debug unless the script output confirms it.
– If it is missing, empty, or suspiciously incomplete, rerun Scripts/clangTidy.sh once and inspect the outputs
before concluding that there are no actionable diagnostics.
3. Decide whether to apply automated replacements, manual fixes, or suppressions.
– Scripts/fixTidy.sh may be used when its preconditions are acceptable. It runs the repository lint wrapper,
applies exported replacements with clang-apply-replacements, and formats the edited sources.
– Scripts/fixTidy.sh requires a clean git worktree and may apply many replacements. If the worktree is dirty or the
desired change must be more selective, handle diagnostics manually.
– After any auto-fix pass, review the resulting diff before making further edits or reporting success.
4. Review each reported diagnostic before changing code.
– Ignore unrelated pre-existing diagnostics outside the script-selected scope.
– If the diagnostic is in scope and valid, fix it with the smallest safe local change.
– If the diagnostic is in scope but a fix would require a non-trivial public API, behavior, or performance change,
suppress it with a tightly scoped // NOLINTBEGIN(diagnostic-name) and // NOLINTEND(diagnostic-name) pair around
the relevant code.
5. Apply severity guidance consistently:
– Error-level diagnostics must be fixed or suppressed.
– Warning-level diagnostics should be fixed only when the public API change and performance impact are minimal.
– Otherwise, suppress Warning-level diagnostics narrowly.
6. Write suppressions carefully:
– Use the exact diagnostic name reported by clang-tidy.
– Keep the suppression scope as small as possible.
– Add a detailed code comment explaining why the warning does not apply to this code and what context makes the
suppression acceptable here.
– Preserve existing suppression comments unless the new change makes them obsolete.
7. Treat the task as incomplete until every in-scope reported diagnostic has been fixed or explicitly suppressed.
– Make at least one textual edit when acting on the diagnostics.
8. Run the full verification loop after the changes:
– Scripts/formatCpp.sh
– cmake --build --preset conan-debug
– Scripts/clangTidy.sh
9. Before finishing, perform a lightweight verification pass:
– confirm edited files are formatted
– confirm the build succeeds
– confirm each diagnostic acted on is now resolved or covered by the intended narrow suppression
10. If verification fails, inspect the failure and continue until the task is actually resolved.
– Fix regressions caused by the new changes.
– If a step fails for an unrelated pre-existing issue, report the exact blocker and separate it clearly from the
diagnostics handled in this pass.
11. End with a concise disposition summary that lists:
– files changed
– diagnostics fixed
– diagnostics suppressed
– any remaining blockers or assumptions
## Direct Tool Use
Prefer repository scripts for normal operation. Direct clang-tidy, run-clang-tidy, or clang-apply-replacements
commands are acceptable only for narrow inspection, targeted verification, or carefully selected replacement
application.
When invoking tools directly:
– Use the exact binary paths and versions that the lint scripts resolved. If Scripts/clangTidy.sh reports
clang-tidy-21, do not substitute an unversioned clang-tidy or another versioned binary unless it is the same
resolved executable.
– Match the wrapper’s flags and inputs: .clang-tidy, the selected compile_commands.json directory, exported fixes
location, header filter, selected file list, CLANG_TIDY_BINARY, and CUDA flags when CUDA files are involved.
– Prefer copying the exact run-clang-tidy command printed by Scripts/clangTidy.sh when reproducing a lint run, along
with any environment variables the wrapper exported.
– For replacement application, use the same clang-apply-replacements version policy as Scripts/fixTidy.sh
(clang-apply-replacements version 17 or newer, with the newest matching binary discovered on PATH).
– Do not let direct commands broaden lint scope, use stale build directories, or bypass diagnostics that
Scripts/clangTidy.sh would report.
## Boundaries
– Do not change the lint scope selection logic. Scripts/clangTidy.sh remains the source of truth for which recently
edited files are in scope.
– Prefer the smallest safe rewrite over opportunistic cleanup.
– Do not use Scripts/runFix.sh.
– Do not use wrapper scripts that invoke Scripts/runFix.sh, such as Scripts/fixAll.sh, unless the user explicitly
changes this instruction.
– You may use Scripts/fixTidy.sh, but only after considering its clean-worktree requirement and broad auto-fix
behavior.
– Do not stop after reviewing diagnostics; continue until each in-scope reported item has been resolved or explicitly
suppressed.
– Do not claim formatting, build, or lint success unless those steps were actually rerun.
## Output Expectations
– Use Markdown only where it adds value.
– Use backticks for file paths, commands, and diagnostic names.
– Keep summaries concise.
– Include a final disposition summary for the diagnostics handled in this pass.
– When assumptions are required, document them at the end.