[clang-tidy][NFC] Use C++17 nested namespaces in clang-tidy headers

We forgot to apply the change to headers in the previous patch,
due to missing "-header-filter" in the run-clang-tidy invocation.

[clang-tidy][NFC] Use C++17 nested namespaces in clang-tidy headers

We forgot to apply the change to headers in the previous patch,
due to missing "-header-filter" in the run-clang-tidy invocation.

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

show more ...

[clang] Remove uses of ::testing::Matcher<const Optional<T> &>

Change a few functions (getCheckTraversalKind, some clang/Tooling/ API, etc)
from llvm::Optional to std::optional.

[clang-tidy] Organize check doc files into subdirectories (NFC)

- Rename doc files to subdirs by module
- Update release notes and check list to use subdirs
- Update add_new_check.py to handle doc s

[clang-tidy] Organize check doc files into subdirectories (NFC)

- Rename doc files to subdirs by module
- Update release notes and check list to use subdirs
- Update add_new_check.py to handle doc subdirs

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

show more ...

[clang-tidy] Add option to ignore macros in readability-function-cognitive-complexity check.

(this was originally part of https://reviews.llvm.org/D96281 and has been split off into its own patch)

[clang-tidy] Add option to ignore macros in readability-function-cognitive-complexity check.

(this was originally part of https://reviews.llvm.org/D96281 and has been split off into its own patch)

If a macro is used within a function, the code inside the macro
doesn't make the code less readable. Instead, for a reader a macro is
more like a function that is called. Thus the code inside a macro
shouldn't increase the complexity of the function in which it is called.
Thus the flag 'IgnoreMacros' is added. If set to 'true' code inside
macros isn't considered during analysis.

This isn't perfect, as now the code of a macro isn't considered at all,
even if it has a high cognitive complexity itself. It might be better if
a macro is considered in the analysis like a function and gets its own
cognitive complexity. Implementing such an analysis seems to be very
complex (if possible at all with the given AST), so we give the user the
option to either ignore macros completely or to let the expanded code
count to the calling function's complexity.

See the code example from vgeof (originally added as note in https://reviews.llvm.org/D96281)

bool doStuff(myClass* objectPtr){
if(objectPtr == nullptr){
LOG_WARNING("empty object");
return false;
}
if(objectPtr->getAttribute() == nullptr){
LOG_WARNING("empty object");
return false;
}
use(objectPtr->getAttribute());
}

The LOG_WARNING macro itself might have a high complexity, but it do not make the
the function more complex to understand like e.g. a 'printf'.

By default 'IgnoreMacros' is set to 'false', which is the original behavior of the check.

Reviewed By: lebedev.ri, alexfh

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

show more ...

[clang-tidy] Add options to describe individual core increments to readability-function-cognitive-complexity check.

Often you are only interested in the overall cognitive complexity of a
function an

[clang-tidy] Add options to describe individual core increments to readability-function-cognitive-complexity check.

Often you are only interested in the overall cognitive complexity of a
function and not every individual increment. Thus the flag
'DescribeBasicIncrements' is added. If it is set to 'true', each increment
is flagged. Otherwise, only the complexity of function with complexity
of at least the threshold are flagged.

By default 'DescribeBasisIncrements' is set to 'true', which is the original behavior of the check.

Added a new test for different flag combinations.

(The option to ignore macros which was original part of this patch will be added in another path)

Reviewed By: lebedev.ri

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

show more ...

[clang-tidy] Simplify function complexity check

Update test to note use of lambda instead of the invisible operator().

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

[clang-tidy] Implement readability-function-cognitive-complexity check

Currently, there is basically just one clang-tidy check to impose
some sanity limits on functions - `clang-tidy-readability-fun

[clang-tidy] Implement readability-function-cognitive-complexity check

Currently, there is basically just one clang-tidy check to impose
some sanity limits on functions - `clang-tidy-readability-function-size`.
It is nice, allows to limit line count, total number of statements,
number of branches, number of function parameters (not counting
implicit `this`), nesting level.

However, those are simple generic metrics. It is still trivially possible
to write a function, which does not violate any of these metrics,
yet is still rather unreadable.

Thus, some additional, slightly more complicated metric is needed.
There is a well-known [[ https://en.wikipedia.org/wiki/Cyclomatic_complexity | Cyclomatic complexity]], but certainly has its downsides.
And there is a [[ https://www.sonarsource.com/docs/CognitiveComplexity.pdf | COGNITIVE COMPLEXITY by SonarSource ]], which is available for opensource on https://sonarcloud.io/.

This check checks function Cognitive Complexity metric, and flags
the functions with Cognitive Complexity exceeding the configured limit.
The default limit is `25`, same as in 'upstream'.

The metric is implemented as per [[ https://www.sonarsource.com/docs/CognitiveComplexity.pdf | COGNITIVE COMPLEXITY by SonarSource ]] specification version 1.2 (19 April 2017), with two notable exceptions:
* `preprocessor conditionals` (`#ifdef`, `#if`, `#elif`, `#else`,
`#endif`) are not accounted for.
Could be done. Currently, upstream does not account for them either.
* `each method in a recursion cycle` is not accounted for.
It can't be fully implemented, because cross-translational-unit
analysis would be needed, which is not possible in clang-tidy.
Thus, at least right now, i completely avoided implementing it.

There are some further possible improvements:
* Are GNU statement expressions (`BinaryConditionalOperator`) really free?
They should probably cause nesting level increase,
and complexity level increase when they are nested within eachother.
* Microsoft SEH support
* ???

Reviewed By: aaron.ballman, JonasToth, lattner

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

show more ...