integrating clang-tidy into openal-soft with cmake

[SeanTolstoyevski]

this changes introduces the integration of Clang-Tidy into the OpenAL-Soft project using CMake.
Clang-Tidy is a static code analysis tool that helps identify and fix potential issues in C++ code.

The changes in this pull request will analyze and apply clang-tidy fixes to the following directories and files:

• al
• alc
• common
• core
• utils/openal-info.c (if enabled)

requirements

• CMake 3.5 or higher see. CMAKE_EXPORT_COMPILE_COMMANDS. compatible for current project cmake version.
• Clang-Tidy (only required if analysis is executed)

usage

1. Configure OpenAL-Soft with CMake using the desired features and add the -DCMAKE_EXPORT_COMPILE_COMMANDS=ON flag to the CMake command line. And you can also set the appropriate clang-tidy program according to the platform, check out the note below.
   e.g. cmake -G "MinGW Makefiles" -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_BUILD_TYPE=Release ..
2. Run Clang-Tidy using the target clang-tidy-check.
   e.g. make clang-tidy-check

Note: LLVM toolset is usually installed as <tool_name>-<version>. The clang-tidy executable file may not be directly on your platform with the clang-tidy name/path. In this case, you can report clang-tidy available on the platform to cmake.
The default executable is clang-tidy.

• For Linux based OSs:

  • Method 1: Before configuring the project with cmake, the environment variable can be defined with export.
    E.g. export CLANG_TIDY_EXECUTABLE=clang-tidy-18
  • Method 2: It can be passed directly to cmake as a flag. .
    E.g. cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCLANG_TIDY_EXECUTABLE=clang-tidy-18 ..

• For Windows OS:

  • Method 1: Before configuring the project with cmake, environment variable can be defined with SET.
    E.g. SET CLANG_TIDY_EXECUTABLE=clang-tidy-18
  • Method 2 does not work on Windows.

importants

1. The fixes applied by clang-tidy are not guaranteed to be correct. Therefore, it is important to re-compile and test the project after running this target.
2. More checks over clang-tidy can be implemented, but this may prevent the project from compiling. A more comprehensive clang-tidy configuration with lint comments to ignore specific cases can be developed in the future.

some questions we need to answer

1. Should it be applied to external libraries/files embedded in the project? example. pffft.
2. What are the necessary / unnecessary checks?

I can make changes based on these two questions.

For the second question i took the basic checks and tested some of them to see if they were compatible with the project. Activating some of them (ex. using explicit in single-argument constructors) requires a lot of time because it requires too many changes. I eliminated these.

[kcat]

Should it be applied to external libraries/files embedded in the project? example. pffft.

For pffft, sure. It's already heavily modified, so more changes to fix other issues isn't a problem (so long as it doesn't adversely affect performance).

What are the necessary / unnecessary checks?

Currently this is what I have enabled with Qt Creator:

-*,bugprone-argument-comment,bugprone-assert-side-effect,bugprone-assignment-in-if-condition,
bugprone-bad-signal-to-kill-thread,bugprone-bool-pointer-implicit-conversion,
bugprone-copy-constructor-init,bugprone-dangling-handle,bugprone-dynamic-static-initializers,
bugprone-fold-init-type,bugprone-forward-declaration-namespace,
bugprone-forwarding-reference-overload,bugprone-implicit-widening-of-multiplication-result,
bugprone-inaccurate-erase,bugprone-incorrect-roundings,bugprone-infinite-loop,
bugprone-integer-division,bugprone-lambda-function-name,bugprone-macro-repeated-side-effects,
bugprone-misplaced-*,bugprone-move-forwarding-reference,bugprone-multiple-statement-macro,
bugprone-narrowing-conversions,bugprone-no-escape,bugprone-not-null-terminated-result,
bugprone-parent-virtual-call,bugprone-posix-return,bugprone-redundant-branch-condition,
bugprone-reserved-identifier,bugprone-shared-ptr-array-mismatch,bugprone-signal-handler,
bugprone-signed-char-misuse,bugprone-sizeof-*,bugprone-spuriously-wake-up-functions,
bugprone-standalone-empty,bugprone-string-*,bugprone-stringview-nullptr,bugprone-suspicious-*,
bugprone-swapped-arguments,bugprone-terminating-continue,bugprone-throw-keyword-missing,
bugprone-too-small-loop-variable,bugprone-undefined-memory-manipulation,
bugprone-undelegated-constructor,bugprone-unhandled-*,bugprone-unused-*,
bugprone-use-after-move,bugprone-virtual-near-miss,clang-*,
concurrency-thread-canceltype-asynchronous,cppcoreguidelines-avoid-c-arrays,
cppcoreguidelines-avoid-goto,cppcoreguidelines-avoid-reference-coroutine-parameters,
cppcoreguidelines-c-copy-assignment-signature,cppcoreguidelines-explicit-virtual-functions,
cppcoreguidelines-interfaces-global-init,cppcoreguidelines-narrowing-conversions,
cppcoreguidelines-no-malloc,cppcoreguidelines-owning-memory,
cppcoreguidelines-prefer-member-initializer,
cppcoreguidelines-pro-bounds-array-to-pointer-decay,
cppcoreguidelines-pro-bounds-pointer-arithmetic,cppcoreguidelines-pro-type-const-cast,
cppcoreguidelines-pro-type-cstyle-cast,cppcoreguidelines-pro-type-member-init,
cppcoreguidelines-pro-type-union-access,cppcoreguidelines-slicing,
cppcoreguidelines-virtual-class-destructor,modernize-avoid-*,modernize-concat-nested-namespaces,
modernize-deprecated-*,modernize-loop-convert,modernize-macro-to-enum,modernize-make-*,
modernize-pass-by-value,modernize-raw-string-literal,modernize-redundant-void-arg,
modernize-replace-*,modernize-return-braced-init-list,modernize-shrink-to-fit,
modernize-unary-static-assert,modernize-use-auto,modernize-use-bool-literals,
modernize-use-default-member-init,modernize-use-emplace,modernize-use-equals-*,
modernize-use-nodiscard,modernize-use-noexcept,modernize-use-nullptr,modernize-use-override,
modernize-use-transparent-functors,modernize-use-uncaught-exceptions,
modernize-use-using,portability-*,readability-const-return-type,readability-container-contains,
readability-container-size-empty,readability-convert-member-functions-to-static,
readability-delete-null-pointer,readability-duplicate-include,readability-else-after-return,
readability-inconsistent-declaration-parameter-name,readability-make-member-function-const,
readability-misleading-indentation,readability-misplaced-array-index,readability-redundant-*,
readability-simplify-subscript-expr,readability-static-definition-in-anonymous-namespace,
readability-string-compare,readability-uniqueptr-delete-release,readability-use-anyofallof

This has a few "false" reports from cppcoreguidelines-pro-bounds-pointer-arithmetic, dependent on implementation details for STL iterators. I'd rather not disable it since it's a more significant safety check.

[SeanTolstoyevski]

hi @kcat,

i added the checks you shared.

i tested the changes on ubuntu and Windows.

there seems to be no problem, but of course i think a review is necessary.

commit was a big :) .
i also made changes to cmake to be able to use clang-tidy on different platforms. this was something i forgot. if there are possible improvements in this, please let me know.