This helps better distinguish warnings that could be disabled via
`.clang-tidy` config (like `clang-diagnostic-literal-conversion`) from
errors that could not be suppressed at all (like
`clang-diagnostic-error`) because it's a hard compiler error.
This patch implements a fix for the false-positive case described in
[issue #134840](https://github.com/llvm/llvm-project/issues/134840) for
the
[bugprone-tagged-union-member-count](https://clang.llvm.org/extra/clang-tidy/checks/bugprone/tagged-union-member-count.html)
clang-tidy check.
The example given in the linked issue was the following:
```C
#include <pthread.h>
typedef enum {
MYENUM_ONE,
MYENUM_TWO,
} myEnumT;
typedef struct {
pthread_mutex_t mtx;
myEnumT my_enum;
} myTypeT;
```
The
[bugprone-tagged-union-member-count](https://clang.llvm.org/extra/clang-tidy/checks/bugprone/tagged-union-member-count.html)
check emits the following a warning for this struct:
```
<source>:8:9: warning: tagged union has more data members (3) than tags (2)! [bugprone-tagged-union-member-count]
8 | typedef struct {
| ^
1 warning generated.
```
The issue is that `pthread_mutex_t` can be a union behind a typedef like
the following:
```C
typedef union
{
struct __pthread_mutex_s __data;
char __size[__SIZEOF_PTHREAD_MUTEX_T];
long int __align;
} pthread_mutex_t;
```
From the checker's point of view therefore `myTypeT` contains a data
member with an enum type and another data member with a union type and
starts analyzing it like a user-defined tagged union.
The proposed solution is that the types from system headers and the std
namespace are no longer candidates to be the enum part or the union part
of a user-defined tagged union. This filtering for enums and the std
namespace may not be strictly necessary in this example, however I added
it preemptively out of (perhaps unnecessary) caution.
Fixes https://github.com/llvm/llvm-project/issues/134840.
`readability-qualified-auto` check currently looks at the unsugared
type, skipping any typedefs, to determine if the variable is a
pointer-type. This may not be the desired behaviour, in particular when
the type depends on compilation flags.
For example
```
#if CONDITION
using Handler = int *;
#else
using Handler = uint64_t;
#endif
```
A more common example is some implementations of `std::array` use
pointers as iterators.
This introduces the IgnoreAliasing option so that
`readability-qualified-auto` does not look beyond typedefs.
---------
Co-authored-by: juanbesa <juanbesa@devvm33299.lla0.facebook.com>
Co-authored-by: Kazu Hirata <kazu@google.com>
Co-authored-by: EugeneZelenko <eugene.zelenko@gmail.com>
Co-authored-by: Baranov Victor <bar.victor.2002@gmail.com>
Upstream is moving towards new create method invocation, add check to flag old
usage that will be deprecated.
---------
Co-authored-by: Baranov Victor <bar.victor.2002@gmail.com>
Co-authored-by: EugeneZelenko <eugene.zelenko@gmail.com>
Closes#132561.
This is a check that rewrites `#if`s and `#elif`s like so:
```cpp
#if defined(MEOW) // -> #ifdef MEOW
#if !defined(MEOW) // -> #ifndef MEOW
```
And, since C23 and C++23:
```cpp
#elif defined(MEOW) // -> #elifdef MEOW
#elif !defined(MEOW) // -> #elifndef MEOW
```
Finds function and variable declarations inside anonymous namespace and
suggests replacing them with ``static`` declarations.
The check will enforce that
[restrict-visibility](https://llvm.org/docs/CodingStandards.html#restrict-visibility)
rule in LLVM Coding Standards is followed correctly (by adding `static`
to functions instead of putting them in anonimous namespace).
The check has additional levels of "strictness" represented by Options.
By default, the check works in the most relaxed way by giving warning
only for methods and functions defined in anonymous namespaces. Also, It
finds `static` functions that are placed inside anonymous namespace -
there is no point in keeping them inside.
Add InsertPlainNamesInForwardDecls option to readability-named-parameter
check to insert parameter names without comments for forward
declarations only.
When enabled, forward declarations get plain parameter names (e.g., `int
param`) while function definitions continue to use commented names
(e.g., `int /*param*/`). Named parameters in forward decls don't cause
compiler warnings and some developers prefer to have names without
comments but in sync between declarations and the definition.
Default behavior remains unchanged
(InsertPlainNamesInForwardDecls=false).
Example with InsertPlainNamesInForwardDecls=true:
```cpp
// Forward declaration - gets plain name because the definition has name.
void func(int param);
void func(int param) { ... = param; }
```
Since std::move is nothing more than a cast, part of STL and not the
language itself, it's easy to provide a custom implementation if one
wishes not to include the entirety of <utility>.
Added flag (MoveFunction) provides a way to continue using this
essential check even with the custom implementation of moving.
---------
Co-authored-by: EugeneZelenko <eugene.zelenko@gmail.com>
Since std::forward is nothing more than a cast, part of STL and not the
language itself, it's easy to provide a custom implementation if one
wishes not to include the entirety of <utility>.
Added flag (ForwardFunction) provides a way to continue using this
essential check even with the custom implementation of forwarding.
---------
Co-authored-by: EugeneZelenko <eugene.zelenko@gmail.com>
Add new clang-tidy check that finds uses of `std::lock_guard` and suggests
replacing them with C++17's more flexible and safer alternative
`std::scoped_lock`.
Here is a small description of how it works for better understanding of
the code:
Two separate AST matchers are registered:
- The first one matches declarations of `std::lock_guard` that are
single in their scope (only one `std::lock_guard` in `CompoundStmt`).
It's an easy case, we can emit warning right away.
- The second one matches `CompoundStmt`'s that have multiple
`std::lock_guard` declarations, which means that we may have consecutive
declarations of `std::lock_guard` that can be replaced by a single
`std::scoped_lock`. In order to ensure that declarations are
consecutive, we need to loop over `Stmt`'s in `CompoundStmt`. Here is a
small example:
```cpp
{
std::mutex m1, m2;
std::lock(m1, m2);
std::lock_guard<std::mutex> l1(m, std::adopt_lock); // first declaration of 'std::lock_guard'
std::lock_guard<std::mutex> l2(m, std::adopt_lock); // second declaration of 'std::lock_guard' that can be merged with first using 'scoped_lock'
}
```
This PR closes https://github.com/llvm/llvm-project/issues/107839.
The sizeof operator misuses in loop conditionals can be a source of
bugs. The common misuse is attempting to retrieve the number of elements
in the array by using the sizeof expression and forgetting to divide the
value by the sizeof the array elements. This results in an incorrect
computation of the array length and requires a warning from the sizeof
checker.
Example:
```
int array[20];
void test_for_loop() {
// Needs warning.
for(int i = 0; i < sizeof(array); i++) {
array[i] = i;
}
}
void test_while_loop() {
int count = 0;
// Needs warning.
while(count < sizeof(array)) {
array[count] = 0;
count = count + 2;
}
}
```
rdar://151403083
---------
Co-authored-by: MalavikaSamak <malavika2@apple.com>
The adds a check that replaces specific numeric literals like `32767`
with the equivalent call to `std::numeric_limits` (such as
`std::numeric_limits<int16_t>::max())`.
Partially addresses #34434, but notably does not handle cases listed in
the title post such as `~0` and `-1`.
Summary:
Replacing by-value parameters with passing by-reference is not safe for
coroutines because the caller may be executed in parallel with the
callee, which increases the chances of resulting in dangling references
and hard-to-find crashes. See for the reference
[cppcoreguidelines-avoid-reference-coroutine-parameters](https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines/avoid-reference-coroutine-parameters.html).
Test Plan: check-clang-tools
New option AllowNoNamespaceComments for
`google-readability-namespace-comments.AllowNoNamespaceComments` is
added.
When true, the check will allow that no namespace comment is present. If
a namespace comment is added but it is not matching, the check will
fail. Default is `false`
Fixes#124264
Sometimes a project may want to enable this check only in C++, and
disable it in C, since the patterns the check warns about are quite
common and idiomatic in C, and there are no better alternatives.
Fixes#140659
Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
Add support for lambda-expression in `use-trailing-return-type` check.
Added two new options:
1. `TransformFunctions` will trigger function declarations to use
trailing return type.
2. `TransformLambdas` will trigger lambda expression to use trailing
return type if it was not stated explicitly.
Fixed false positives when lambda was matched as a function in C++11
mode.
Closes https://github.com/llvm/llvm-project/issues/95711
Anchors are automatically generated, but adding another anchor with the
same name hides the anchor that we actually want. Simply removing the
unnecessary self-referential anchor `lifetimebound` fixes the links.
The documentation for coro_disable_lifetimebound and coro_lifetimebound
also had an unnecessary redirection. It's possible to change the link
text to differ from the heading, but I think that's not necessary here.
Also fix a reference in clang-tidy that was using the (unstable)
numbered anchor.
Fix false positives in `bugprone-crtp-constructor-accessibility` check
on deleted constructors that cannot be used to construct objects, even
if they have public or protected access.
Closes https://github.com/llvm/llvm-project/issues/131737.
**Edit:**
I suggest we avoid diagnosing initializers for `std::array` type. The
fixit provided is incorrect as observed in **#133715.** The only
workaround would require C99-style array designators which don’t really
align with the purpose of this check. This would also generate extra
compiler warnings.
Fixes#133715
Add `AllowedTypes` options to support custom defined char like type.
treat `unsigned char` and `signed char` as char like type by default.
The allowed types only effect when the var decl or explicit cast to this
non-canonical type names.
Fixed: #133425
Improve `bugprone-capturing-this-in-member-variable` check:
Added support of `bind`-like functions that capture and store `this`
pointer in class member.
Closes https://github.com/llvm/llvm-project/issues/131220.
Improved "options" sections of various checks:
1. Added Options keyword to be a delimiter between "body" and "options"
parts of docs
2. Added default values where were absent.
3. Changed double-tick to single-tick in default values.
---------
Co-authored-by: EugeneZelenko <eugene.zelenko@gmail.com>
Improved "options" sections of `bugprone-` and `modernize-` checks:
1. Added `Options` keyword to be a delimiter between "body" and
"options" parts of docs
2. Added default values where was absent.
3. Improved readability of some default values by converting `1` to
`true`.
Improve docs for `bugprone-argument-comment` check by writing explicitly
default values for options.
Before this change, it was unclear what values are default.
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>
