Omitted new checks which produce too many matches or which are
controversial (e.g. readability-identifier-length).
New checks:
- misc-misleading-bidirectional + misc-misleading-identifier
Detects potential attack as described in the Trojan Source attack
- modernize-macro-to-enum
Replaces groups of adjacent macros with an unscoped anonymous enum
- modernize-shrink-to-fit
Replace copy and swap tricks on shrinkable containers with the
shrink_to_fit() method call
- modernize-use-transparent-functors
Prefer transparent functors to non-transparent ones
- modernize-use-uncaught-exceptions
This check will warn on calls to std::uncaught_exception and replace
them with calls to std::uncaught_exceptions (uncaught_exception was
deprecated with C++17)
- performance-no-int-to-ptr
Diagnoses every integer to pointer cast
- readability-duplicate-include
Looks for duplicate includes and removes them
- readability-redundant-preprocessor
Finds potentially redundant preprocessor directives
- bugprone-lambda-function-name
Checks for attempts to get the name of a function from within a lambda
expression
- bugprone-redundant-branch-condition
Finds condition variables in nested if statements that were also
checked in the outer if statement and were not changed
- bugprone-shared-ptr-array-mismatch
Finds initializations of C++ shared pointers to non-array type that
are initialized with an array
- bugprone-stringview-nullptr
Checks for various ways that the const CharT* constructor of
std::basic_string_view can be passed a null argument and replaces them
with the default constructor in most cases
- bugprone-suspicious-memory-comparison
Finds potentially incorrect calls to memcmp() based on properties of
the arguments
When I tried to add cool new clang-tidy 14 warnings, I noticed that the
current clang-tidy settings already produce a ton of warnings. This
commit addresses many of these. Almost all of them were non-critical,
i.e. C vs. C++ style casts.
- enable_if is usually regarded as fragile and unreadable
- C++20 concepts are much easier to read and produce more expressive error messages
- this is follow-up to PR #35347 but this time most of the remaining and
more complex usages of enable_if in the codebase were replaced.
