2020-04-08 00:26:40 +08:00
|
|
|
set(LLVM_LINK_COMPONENTS
|
|
|
|
|
FrontendOpenMP
|
|
|
|
|
Support
|
|
|
|
|
)
|
2014-03-05 21:14:32 +08:00
|
|
|
|
|
|
|
|
add_clang_library(clangTidyMiscModule
|
2016-01-09 00:37:11 +08:00
|
|
|
DefinitionsInHeadersCheck.cpp
|
2014-03-05 21:14:32 +08:00
|
|
|
MiscTidyModule.cpp
|
2018-09-20 08:02:55 +08:00
|
|
|
MisplacedConstCheck.cpp
|
2015-09-29 21:12:21 +08:00
|
|
|
NewDeleteOverloadsCheck.cpp
|
[clang-tidy] misc-no-recursion: a new check
Summary:
Recursion is a powerful tool, but like any tool
without care it can be dangerous. For example,
if the recursion is unbounded, you will
eventually run out of stack and crash.
You can of course track the recursion depth
but if it is hardcoded, there can always be some
other environment when that depth is too large,
so said magic number would need to be env-dependent.
But then your program's behavior is suddenly more env-dependent.
Also, recursion, while it does not outright stop optimization,
recursive calls are less great than normal calls,
for example they hinder inlining.
Recursion is banned in some coding guidelines:
* SEI CERT DCL56-CPP. Avoid cycles during initialization of static objects
* JPL 2.4 Do not use direct or indirect recursion.
* I'd say it is frowned upon in LLVM, although not banned
And is plain unsupported in some cases:
* OpenCL 1.2, 6.9 Restrictions: i. Recursion is not supported.
So there's clearly a lot of reasons why one might want to
avoid recursion, and replace it with worklist handling.
It would be great to have a enforcement for it though.
This implements such a check.
Here we detect both direct and indirect recursive calls,
although since clang-tidy (unlike clang static analyzer)
is CTU-unaware, if the recursion transcends a single standalone TU,
we will naturally not find it :/
The algorithm is pretty straight-forward:
1. Build call-graph for the entire TU.
For that, the existing `clang::CallGraph` is re-used,
although it had to be modified to also track the location of the call.
2. Then, the hard problem: how do we detect recursion?
Since we have a graph, let's just do the sane thing,
and look for Strongly Connected Function Declarations - widely known as `SCC`.
For that LLVM provides `llvm::scc_iterator`,
which is internally an Tarjan's DFS algorithm, and is used throught LLVM,
so this should be as performant as possible.
3. Now that we've got SCC's, we discard those that don't contain loops.
Note that there may be more than one loop in SCC!
4. For each loopy SCC, we call out each function, and print a single example
call graph that shows recursion -- it didn't seem worthwhile enumerating
every possible loop in SCC, although i suppose it could be implemented.
* To come up with that call graph cycle example, we start at first SCC node,
see which callee of the node is within SCC (and is thus known to be in cycle),
and recurse into it until we hit the callee that is already in call stack.
Reviewers: JonasToth, aaron.ballman, ffrankies, Eugene.Zelenko, erichkeane, NoQ
Reviewed By: aaron.ballman
Subscribers: Charusso, Naghasan, bader, riccibruno, mgorny, Anastasia, xazax.hun, cfe-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D72362
2020-02-14 04:34:13 +08:00
|
|
|
NoRecursionCheck.cpp
|
2015-09-30 22:09:38 +08:00
|
|
|
NonCopyableObjects.cpp
|
[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
2018-10-19 04:16:44 +08:00
|
|
|
NonPrivateMemberVariablesInClassesCheck.cpp
|
2016-04-27 01:30:30 +08:00
|
|
|
RedundantExpressionCheck.cpp
|
2015-03-02 18:46:43 +08:00
|
|
|
StaticAssertCheck.cpp
|
2015-10-10 04:42:44 +08:00
|
|
|
ThrowByValueCatchByReferenceCheck.cpp
|
2018-09-20 08:02:55 +08:00
|
|
|
UnconventionalAssignOperatorCheck.cpp
|
2016-04-19 21:48:39 +08:00
|
|
|
UniqueptrResetReleaseCheck.cpp
|
2015-08-01 00:08:10 +08:00
|
|
|
UnusedAliasDeclsCheck.cpp
|
2015-07-20 09:06:44 +08:00
|
|
|
UnusedParametersCheck.cpp
|
2016-04-19 21:48:39 +08:00
|
|
|
UnusedUsingDeclsCheck.cpp
|
2014-03-05 21:14:32 +08:00
|
|
|
|
|
|
|
|
LINK_LIBS
|
2016-09-14 21:33:11 +08:00
|
|
|
clangAnalysis
|
2014-03-05 21:14:32 +08:00
|
|
|
clangAST
|
|
|
|
|
clangASTMatchers
|
|
|
|
|
clangBasic
|
2014-07-14 13:01:53 +08:00
|
|
|
clangLex
|
2018-12-12 16:25:16 +08:00
|
|
|
clangSerialization
|
2014-03-05 21:14:32 +08:00
|
|
|
clangTidy
|
2015-10-07 00:32:50 +08:00
|
|
|
clangTidyUtils
|
2016-05-12 05:32:29 +08:00
|
|
|
clangTooling
|
2014-03-05 21:14:32 +08:00
|
|
|
)
|