Run misc-use-internal-linkage check over clang-tidy code.
Also fixed a couple of other clang-tidy warnings.
Apart from issues in header files, all '.cpp' in
`clang-tools-extra/clang-tidy` must be clang-tidy clear now.
Finds lambda captures that capture the ``this`` pointer and store it as
class
members without handle the copy and move constructors and the
assignments.
Capture this in a lambda and store it as a class member is dangerous
because the
lambda can outlive the object it captures. Especially when the object is
copied
or moved, the captured ``this`` pointer will be implicitly propagated to
the
new object. Most of the time, people will believe that the captured
``this``
pointer points to the new object, which will lead to bugs.
Fixes: #120863
---------
Co-authored-by: Baranov Victor <70346889+vbvictor@users.noreply.github.com>
Co-authored-by: Baranov Victor <bar.victor.2002@gmail.com>
It wants to find unintended character output from `uint8_t` and `int8_t`
to an ostream.
e.g.
```c++
uint8_t v = 9;
std::cout << v;
```
---------
Co-authored-by: whisperity <whisperity@gmail.com>
This checks that classes/structs inheriting from
``std::enable_shared_from_this`` does so with public inheritance, so it
prevents crashes due to ``std::make_shared`` and ``shared_from_this()``
getting called when the internal weak pointer was not initialized (e.g.
due to private inheritance).
According to #116591.
> Coding guidelines should "cherry-pick" (and posddsibly
configure/harden/make more strict) base checks.
We should move narrowing conversion to bugprone and keep alias in
cppcoreguidelines
This change moves the `alpha.nondeterministic.PointerSorting` and
`alpha.nondeterministic.PointerIteration` static analyzer checkers to a
single `clang-tidy` check. Those checkers were implemented as simple
`clang-tidy` check-like code, wrapped in the static analyzer framework.
The documentation was updated to describe what the checks can and cannot
do, and testing was completed on a broad set of open-source projects.
Co-authored-by: Vince Bridgers <vince.a.bridgers@ericsson.com>
To detect unsafe usages of casting a pointer to another via copying
the bytes from one into the other, either via std::bit_cast or via
memcpy. This is currently not caught by any other means.
Fixes#106987
---------
Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
This patch introduces a new check to find mismatches between the number
of data members in a union and the number enum values present in
variant-like structures.
Variant-like types can look something like this:
```c++
struct variant {
enum {
tag1,
tag2,
} kind;
union {
int i;
char c;
} data;
};
```
The kind data member of the variant is supposed to tell which data
member of the union is valid, however if there are fewer enum values
than union members, then it is likely a mistake.
The opposite is not that obvious, because it might be fine to have more
enum values than union data members, but for the time being I am curious
how many real bugs can be caught if we give a warning regardless.
This patch also contains a heuristic where we try to guess whether the
last enum constant is actually supposed to be a tag value for the
variant or whether it is just holding how many enum constants have been
created.
Patch by Gábor Tóthvári!
This check identifies suspicious usages of std::string_view::data() that
could lead to reading out-of-bounds data due to inadequate or incorrect
string null termination.
Closes#80854
Check that flags chained comparison expressions,
such as a < b < c or a == b == c, which may have
unintended behavior due to implicit operator
associativity.
Moved from Phabricator (D144429).
Introduce a new (off by default) clang tidy check to ensure that
variables of a specific type are always used even if -Wunused-variables
wouldn't generate a warning.
This check has already caught a couple of different bugs on the codebase
I work on, where not handling a future means that lifetimes may not be
kept alive properly as an async chunk of code may run after a class has
been destroyed, etc.
I would like to upstream it because I believe there could be other
applications of this check that would be useful in different contexts.
---------
Signed-off-by: Tyler Rockwood <rockwood@redpanda.com>
Detects incorrect usages of std::enable_if that don't name the
nested 'type' type.
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D157239
Detects potentially unintentional and redundant conversions where a value is
extracted from an optional-like type and then used to create a new instance of
the same optional-like type.
Reviewed By: xgupta
Differential Revision: https://reviews.llvm.org/D147357
Detects when a variable is both incremented/decremented and referenced inside a
complex condition and suggests moving them outside to avoid ambiguity in the
variable's value.
Reviewed By: xgupta
Differential Revision: https://reviews.llvm.org/D149015
Detects implicit conversions between pointers of different levels of
indirection.
Reviewed By: xgupta
Differential Revision: https://reviews.llvm.org/D149084
While clang warns about a possibly incomplete switch statement when switching over an enum variable and failing to cover all enum values (either explicitly or with a default case), no such warning is emitted if a plain integer variable is used as switch variable.
Add a clang-tidy check to diagnose these scenarios.
No fixit hint is provided since there are multiple possible solutions.
Differential Revision: https://reviews.llvm.org/D4784
Detect implicit and explicit conversions of enum to bool,
when enum doesn't have a enumerator with value equal to 0.
In theory such conversion should always return TRUE.
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D144036
Checks for unsafe functions, mostly those listed in the
SEI CERT C Coding Standard Recommendation `MSC24-C` and Rule `MSC33-C`.
For the listed functions, an alternative, more secure replacement is
suggested, if such is available. The checker heavily relies on the
functions from "Annex K" (Bounds-checking interfaces) from C11, but
there are several other recommendations not directly from Annex K.
Differential Revision: http://reviews.llvm.org/D91000
Reviewed-By: aaron.ballman, dkrupp, steakhal, whisperity
Co-Authored-By: Tamás Koller <koller.tamas1996@gmail.com>
Co-Authored-By: Balázs Benics <balazs.benics@sigmatechnology.se>
Co-Authored-By: Whisperity <whisperity@gmail.com>
Adds a clang-tidy check for the incorrect use of `empty()` on a
container when the result of the call is ignored.
Authored-by: Abraham Corea Diaz <abrahamcd@google.com>
Co-authored-by: Denis Nikitin <denik@google.com>
Reviewed By: cjdb
Differential Revision: https://reviews.llvm.org/D128372
Add a check to detect usages of `realloc` where the result is assigned
to the same variable (or field) as passed to the first argument.
Reviewed By: steakhal, martong
Differential Revision: https://reviews.llvm.org/D133119
new clang-tidy checker for assignments within the condition clause of an 'if' statement.
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D127114
This check verifies the safety of access to `std::optional` and related
types (including `absl::optional`). It is based on a corresponding Clang
Dataflow Analysis, which does most of the work. This check merely runs it and
converts its findings into diagnostics.
Differential Revision: https://reviews.llvm.org/D121120
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. For the comparison operators, braced initializer list does not compile so instead a call to `.empty()` or the empty string literal are used, where appropriate.
This prevents code from invoking behavior which is unconditionally undefined. The single-argument `const CharT*` constructor does not check for the null case before dereferencing its input. The standard is slated to add an explicitly-deleted overload to catch some of these cases: wg21.link/p2166
https://reviews.llvm.org/D114823 is a companion change to prevent duplicate warnings from the `bugprone-string-constructor` check.
Reviewed By: ymandel
Differential Revision: https://reviews.llvm.org/D113148
Finds function definitions where parameters of convertible types follow
each other directly, making call sites prone to calling the function
with swapped (or badly ordered) arguments.
Such constructs are usually the result of inefficient design and lack of
exploitation of strong type capabilities that are possible in the
language.
This check finds and flags **function definitions** and **not** call
sites!
Reviewed By: aaron.ballman, alexfh
Differential Revision: http://reviews.llvm.org/D69560
Overflows are never fun.
In most cases (in most of the code), they are rare,
because usually you e.g. don't have as many elements.
However, it's exceptionally easy to fall into this pitfail
in code that deals with images, because, assuming 4-channel 32-bit FP data,
you need *just* ~269 megapixel image to case an overflow
when computing at least the total byte count.
In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs:
* https://github.com/darktable-org/darktable/pull/7740
* https://github.com/darktable-org/darktable/pull/7419
* eea1989f2c
* 70626dd95b
* https://github.com/darktable-org/darktable/pull/670
* 38c69fb1b2
and yet they clearly keep resurfacing still.
It would be immensely helpful to have a diagnostic for those patterns,
which is what this change proposes.
Currently, i only diagnose the most obvious case, where multiplication
is directly widened with no other expressions inbetween,
(i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`)
however that might be worth relaxing later.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D93822
SIG30-C. Call only asynchronous-safe functions within signal handlers
First version of this check, only minimal list of functions is allowed
("strictly conforming" case), for C only.
Differential Revision: https://reviews.llvm.org/D87449
Checking the same condition again in a nested `if` usually make no sense,
except if the value of the expression could have been changed between
the two checks. Although compilers may optimize this out, such code is
suspicious: the programmer may have meant to check something else.
Therefore it is worth to find such places in the code and notify the
user about the problem.
This patch implements a basic check for this problem. Currently it
only detects redundant conditions where the condition is a variable of
integral type. It also detects the possible bug if the variable is in an
//or// or //and// logical expression in the inner if and/or the variable
is in an //and// logical expression in the outer if statement. Negated
cases are not handled yet.
Differential Revision: https://reviews.llvm.org/D81272
The block arguments in dispatch_async() and dispatch_after() are
guaranteed to escape. If those blocks capture any pointers with the
noescape attribute then it is an error.
This reverts commit 1e0669bfe05f0f48ee88152c4a1d581f484f8d67
(and follow-ups 698a12712920c214e39bb215fe26fad2e099425b and
52bbdad7d63fd060d102b3591b433d116a982255).
The tests fail fail on Windows, see https://reviews.llvm.org/D74669
