First part, updated most UTF8, hashing, memory and codecs. Except
utf8lower and upper, maybe a little later.
That includes huge amount of research with movemask dealing. Exact
details and blog post TBD.
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.
