Remove 'IgnoreDestructors = true' from cppcoreguidelines-explicit-virtual-functions

This requirement was introduced in the C++ Core guidelines in 2016:

https://github.com/isocpp/CppCoreGuidelines/c

Remove 'IgnoreDestructors = true' from cppcoreguidelines-explicit-virtual-functions

This requirement was introduced in the C++ Core guidelines in 2016:

https://github.com/isocpp/CppCoreGuidelines/commit/1894380d0abf4d7d49a983005647e0d41ecbf214

Then clang-tidy got updated to comply with the rule.

However in 2019 this decision was reverted:

https://github.com/isocpp/CppCoreGuidelines/commit/5fdfb20b760c5307bf86873798a146fcd7e912e6

Therefore we need to apply the correct configuration to
clang-tidy again.

This also makes this cppcoreguidelines check consistent
with the other 2 alias checks: hicpp-use-override and
modernize-use-override.

Additionally, add another RUN line to the unit test,
to make sure cppcoreguidelines-explicit-virtual-functions
is tested.

show more ...

[clang-tidy] cppcoreguidelines-virtual-base-class-destructor: a new check

Finds base classes and structs whose destructor is neither public and
virtual nor protected and non-virtual.
A base class's

[clang-tidy] cppcoreguidelines-virtual-base-class-destructor: a new check

Finds base classes and structs whose destructor is neither public and
virtual nor protected and non-virtual.
A base class's destructor should be specified in one of these ways to
prevent undefined behaviour.

Fixes are available for user-declared and implicit destructors that are
either public and non-virtual or protected and virtual.

This check implements C.35 [1] from the CppCoreGuidelines.

Reviewed By: aaron.ballman, njames93

Differential Revision: http://reviews.llvm.org/D102325

[1]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-dtor-virtual

show more ...

[clang-tidy][NFC] Update tests and Default options to use boolean value

Change instances where options which are boolean are assigned the value 1|0 to use true|false instead.

Reviewed By: aaron.bal

[clang-tidy][NFC] Update tests and Default options to use boolean value

Change instances where options which are boolean are assigned the value 1|0 to use true|false instead.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D101721

show more ...

[clang-tidy] New check cppcoreguidelines-prefer-member-initializer

Finds member initializations in the constructor body which can be placed
into the initialization list instead. This does not only i

[clang-tidy] New check cppcoreguidelines-prefer-member-initializer

Finds member initializations in the constructor body which can be placed
into the initialization list instead. This does not only improves the
readability of the code but also affects positively its performance.
Class-member assignments inside a control statement or following the
first control statement are ignored.

Differential Revision: https://reviews.llvm.org/D71199

show more ...

Revert "[clang-tidy] New check readability-prefer-member-initializer"

Either contains unbounded loops, or has *very* high runtime,
100+x of all the current clang-tidy checks.

This reverts commit f5

Revert "[clang-tidy] New check readability-prefer-member-initializer"

Either contains unbounded loops, or has *very* high runtime,
100+x of all the current clang-tidy checks.

This reverts commit f5fd7486d6c0debb465de3e927fcc31884874280.

show more ...

[clang-tidy] New check readability-prefer-member-initializer

Finds member initializations in the constructor body which can
be placed to the member initializers of the constructor instead.
This does

[clang-tidy] New check readability-prefer-member-initializer

Finds member initializations in the constructor body which can
be placed to the member initializers of the constructor instead.
This does not only improves the readability of the code but also
affects positively its performance. Class-member assignments
inside a control statement or following the first control
statement are ignored.

Differential Revision: https://reviews.llvm.org/D71199

show more ...

Add CppCoreGuidelines I.2 "Avoid non-const global variables" check

Cpp Core Guideline I.2, a.k.a "Avoid non-const global variables"
For detailed documentation, see:
https://github.com/isocpp/CppCore

Add CppCoreGuidelines I.2 "Avoid non-const global variables" check

Cpp Core Guideline I.2, a.k.a "Avoid non-const global variables"
For detailed documentation, see:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#i2-avoid-non-const-global-variables

show more ...

Add the misc-init-local-variables check.

This checks finds all primitive type local variables (integers, doubles, pointers) that are declared without an initial value. Includes fixit functionality t

Add the misc-init-local-variables check.

This checks finds all primitive type local variables (integers, doubles, pointers) that are declared without an initial value. Includes fixit functionality to initialize said variables with a default value. This is zero for most types and NaN for floating point types. The use of NaNs is copied from the D programming language.

Patch by Jussi Pakkanen.

llvm-svn: 373489

show more ...

Fix file headers. NFC

llvm-svn: 355188

[clang-tidy] added cppcoreguidelines-explicit-virtual-functions

Addresses the bugzilla bug #30397. (https://bugs.llvm.org/show_bug.cgi?id=30397)
modernize-use-override suggests that destructors requ

[clang-tidy] added cppcoreguidelines-explicit-virtual-functions

Addresses the bugzilla bug #30397. (https://bugs.llvm.org/show_bug.cgi?id=30397)
modernize-use-override suggests that destructors require the override specifier
and the CPP core guidelines do not recommend this.

Patch by lewmpk.

Differential Revision: https://reviews.llvm.org/D58731

llvm-svn: 355093

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[clang-tidy] Avoid C arrays check

Summary:
[[ https://bugs.llvm.org/show_bug.cgi?id=39224 | PR39224 ]]
As discussed, we can't always do the transform automatically due to that array-to-pointer decay

[clang-tidy] Avoid C arrays check

Summary:
[[ https://bugs.llvm.org/show_bug.cgi?id=39224 | PR39224 ]]
As discussed, we can't always do the transform automatically due to that array-to-pointer decay of C array.
In order to detect whether we can do said transform, we'd need to be able to see all usages of said array,
which is, i would say, rather impossible if e.g. it is in the header.
Thus right now no fixit exists.

Exceptions: `extern "C"` code.

References:
* [[ https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es27-use-stdarray-or-stack_array-for-arrays-on-the-stack | CPPCG ES.27: Use std::array or stack_array for arrays on the stack ]]
* [[ https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slcon1-prefer-using-stl-array-or-vector-instead-of-a-c-array | CPPCG SL.con.1: Prefer using STL array or vector instead of a C array ]]
* HICPP `4.1.1 Ensure that a function argument does not undergo an array-to-pointer conversion`
* MISRA `5-2-12 An identifier with array type passed as a function argument shall not decay to a pointer`

Reviewers: aaron.ballman, JonasToth, alexfh, hokein, xazax.hun

Reviewed By: JonasToth

Subscribers: Eugene.Zelenko, mgorny, rnkovacs, cfe-commits

Tags: #clang-tools-extra

Differential Revision: https://reviews.llvm.org/D53771

llvm-svn: 346835

show more ...

[clang-tidy] implement cppcoreguidelines macro rules

Summary:
In short macros are discouraged by multiple rules (and sometimes reference randomly). [Enum.1], [ES.30], [ES.31]
This check allows only

[clang-tidy] implement cppcoreguidelines macro rules

Summary:
In short macros are discouraged by multiple rules (and sometimes reference randomly). [Enum.1], [ES.30], [ES.31]
This check allows only headerguards and empty macros for annotation.

Reviewers: aaron.ballman, hokein

Reviewed By: aaron.ballman

Subscribers: jbcoe, Eugene.Zelenko, klimek, nemanjai, mgorny, xazax.hun, kbarton, cfe-commits

Differential Revision: https://reviews.llvm.org/D41648

llvm-svn: 344940

show more ...

[clang-tidy] Non-private member variables in classes (MISRA, CppCoreGuidelines, HICPP)

Summary:
Finds classes that not only contain the data (non-static member variables),
but also have logic (non-s

[clang-tidy] Non-private member variables in classes (MISRA, CppCoreGuidelines, HICPP)

Summary:
Finds classes that not only contain the data (non-static member variables),
but also have logic (non-static member functions), and diagnoses all member
variables that have any other scope other than `private`. They should be
made `private`, and manipulated exclusively via the member functions.

Optionally, classes with all member variables being `public` could be
ignored, and optionally all `public` member variables could be ignored.

Options
-------

* IgnoreClassesWithAllMemberVariablesBeingPublic

Allows to completely ignore classes if **all** the member variables in that
class have `public` visibility.

* IgnorePublicMemberVariables

Allows to ignore (not diagnose) **all** the member variables with `public`
visibility scope.

References:
* MISRA 11-0-1 Member data in non-POD class types shall be private.
* https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c2-use-class-if-the-class-has-an-invariant-use-struct-if-the-data-members-can-vary-independently
* https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-private
* https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-protected

Reviewers: JonasToth, aaron.ballman, alexfh, hokein, xazax.hun

Reviewed By: aaron.ballman

Subscribers: Eugene.Zelenko, zinovy.nis, cfe-commits, rnkovacs, nemanjai, mgorny, xazax.hun, kbarton

Tags: #clang-tools-extra

Differential Revision: https://reviews.llvm.org/D52771

llvm-svn: 344757

show more ...

[clang-tidy] NFC reorder registering in CppCoreGuidelines module

llvm-svn: 343673

Add a new check to the readability module that flags uses of "magic numbers" (both floating-point and integral).

Patch by Florin Iucha <[email protected]>

llvm-svn: 339516

[clang-tidy] new cppcoreguidelines-narrowing-conversions check.

Summary:
Checks for narrowing conversions, e.g.

int i = 0;
i += 0.1;

This has what some might consider false positives for:
i += cei

[clang-tidy] new cppcoreguidelines-narrowing-conversions check.

Summary:
Checks for narrowing conversions, e.g.

int i = 0;
i += 0.1;

This has what some might consider false positives for:
i += ceil(d);

Reviewers: alexfh, hokein

Subscribers: srhines, nemanjai, mgorny, JDevlieghere, xazax.hun, kbarton

Differential Revision: https://reviews.llvm.org/D38455

llvm-svn: 333066

show more ...

[clang-tidy] implement check for goto

The usage of `goto` is discourage in C++ since forever. This check implements
a warning for every `goto`. Even though there are (rare) valid use cases for
`goto

[clang-tidy] implement check for goto

The usage of `goto` is discourage in C++ since forever. This check implements
a warning for every `goto`. Even though there are (rare) valid use cases for
`goto`, better high level constructs should be used.

`goto` is used sometimes in C programs to free resources at the end of
functions in the case of errors. This pattern is better implemented with
RAII in C++.

Reviewers: aaron.ballman, alexfh, hokein

Reviewed By: aaron.ballman

Subscribers: lebedev.ri, jbcoe, Eugene.Zelenko, klimek, nemanjai, mgorny, xazax.hun, kbarton, cfe-commits

Differential Revision: https://reviews.llvm.org/D41815

llvm-svn: 322626

show more ...

[clang-tidy] Implement type-based check for `gsl::owner`

This check implements the typebased semantic of `gsl::owner`.
Meaning, that
- only `gsl::owner` is allowed to get `delete`d
- `new` expressi

[clang-tidy] Implement type-based check for `gsl::owner`

This check implements the typebased semantic of `gsl::owner`.
Meaning, that
- only `gsl::owner` is allowed to get `delete`d
- `new` expression must be assigned to `gsl::owner`
- function calls that expect `gsl::owner` as argument, must get either an owner
or a newly created and recognized resource (in the moment only `new`ed memory)
- assignment to `gsl::owner` must be either a resource or another owner
- functions returning an `gsl::owner` are considered as factories, and their result
must be assigned to an `gsl::owner`
- classes that have an `gsl::owner`-member must declare a non-default destructor

There are some problems that occur when typededuction is in place.
For example `auto Var = function_that_returns_owner();` the type of `Var` will not be
an `gsl::owner`. This case is catched, and explicitly noted.

But cases like fully templated functions
```
template <typename T>
void f(T t) { delete t; }
// ...
f(gsl::owner<int*>(new int(42)));
```
Will created false positive (the deletion is problematic), since the type deduction
removes the wrapping `typeAlias`.

Codereview in D36354

llvm-svn: 313067

show more ...

[clang-tidy] Revert Implement type-based check for gsl::owner

This should unbreak the buildbot for visual studio 2015 for now.

llvm-svn: 313059

[clang-tidy] Implement type-based check for `gsl::owner`

This check implements the typebased semantic of `gsl::owner`.
Meaning, that
- only `gsl::owner` is allowed to get `delete`d
- `new` expressi

[clang-tidy] Implement type-based check for `gsl::owner`

This check implements the typebased semantic of `gsl::owner`.
Meaning, that
- only `gsl::owner` is allowed to get `delete`d
- `new` expression must be assigned to `gsl::owner`
- function calls that expect `gsl::owner` as argument, must get either an owner
or a newly created and recognized resource (in the moment only `new`ed memory)
- assignment to `gsl::owner` must be either a resource or another owner
- functions returning an `gsl::owner` are considered as factories, and their result
must be assigned to an `gsl::owner`
- classes that have an `gsl::owner`-member must declare a non-default destructor

There are some problems that occur when typededuction is in place.
For example `auto Var = function_that_returns_owner();` the type of `Var` will not be
an `gsl::owner`. This case is catched, and explicitly noted.

But cases like fully templated functions
```
template <typename T>
void f(T t) { delete t; }
// ...
f(gsl::owner<int*>(new int(42)));
```
Will created false positive (the deletion is problematic), since the type deduction
removes the wrapping `typeAlias`.

Please give your comments :)

llvm-svn: 313043

show more ...

[Clang-tidy] check for malloc, realloc and free calls

Summary:
This checker flags the use of C-style memory management functionality and notes about modern alternatives.
In an earlier revision it tr

[Clang-tidy] check for malloc, realloc and free calls

Summary:
This checker flags the use of C-style memory management functionality and notes about modern alternatives.
In an earlier revision it tried to autofix some kind of patterns, but that was a bad idea. Since memory management can be so widespread in a program, manual updating is most likely necessary.
Maybe for special cases, there could be later additions to this basic checker.

This is the first checker I wrote and I never did something with clang (only compiling programs). So whenever I missed conventions or did plain retarded stuff, feel free to point it out! I am willing to fix them and write a better checker.

I hope the patch does work, I never did this either. On a testapply in my repository it did, but I am pretty unconfident in my patching skills :)

Reviewers: aaron.ballman, hokein, alexfh, malcolm.parsons

Subscribers: cfe-commits, JDevlieghere, nemanjai, Eugene.Zelenko, Prazek, mgorny, modocache

Tags: #clang-tools-extra

Differential Revision: https://reviews.llvm.org/D26167

Patch by Jonas Toth!

llvm-svn: 289546

show more ...

[clang-tools-extra] Format sources with clang-format. NFC.

Summary:
Ran clang-format on all .c/.cpp/.h files in clang-tools-extra.
Excluded the test, unittests, clang-reorder-fields, include-fixer,

[clang-tools-extra] Format sources with clang-format. NFC.

Summary:
Ran clang-format on all .c/.cpp/.h files in clang-tools-extra.
Excluded the test, unittests, clang-reorder-fields, include-fixer, modularize and pptrace directories.

Reviewers: klimek, alexfh

Subscribers: nemanjai

Tags: #clang-tools-extra

Differential Revision: https://reviews.llvm.org/D26329

llvm-svn: 286221

show more ...

[clang-tidy] add check cppcoreguidelines-special-member-functions

Summary:
Check for classes that violate the rule of five and zero as specified in CppCoreGuidelines:

"If a class defines or deletes

[clang-tidy] add check cppcoreguidelines-special-member-functions

Summary:
Check for classes that violate the rule of five and zero as specified in CppCoreGuidelines:

"If a class defines or deletes a default operation then it should define or delete them all."

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all.

Reviewers: alexfh, sbenza, aaron.ballman

Subscribers: Prazek, Eugene.Zelenko, cfe-commits, ericLemanissier, nemanjai

Projects: #clang-tools-extra

Differential Revision: https://reviews.llvm.org/D22513

llvm-svn: 277262

show more ...

Revert "Revert "[clang-tidy] new cppcoreguidelines-slicing""

Second try for r276408

llvm-svn: 276415