Check `bugprone-signal-handler` is improved to check for
C++-specific constructs in signal handlers. This check is
valid until C++17.
Reviewed By: whisperity
Differential Revision: https://reviews.llvm.org/D118996
Flags uses of const-qualified and reference data members in structs.
Implements rule C.12 of C++ Core Guidelines.
Differential Revision: https://reviews.llvm.org/D126880
Check `bugprone-signal-handler` is improved to check for
C++-specific constructs in signal handlers. This check is
valid until C++17.
Reviewed By: whisperity
Differential Revision: https://reviews.llvm.org/D118996
Without the "found declaration" it is later not possible to know where the operator declaration
was brought into the scope calling it.
The initial motivation for this fix came from #55095. However, this also has an influence on
`clang -ast-dump` which now prints a `UsingShadow` attribute for operators only visible through
`using` statements. Also, clangd now correctly references the `using` statement instead of the
operator directly.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D129973
This patch connects the check for const-correctness with the new general
utility to add `const` to variables.
The code-transformation is only done, if the detected variable for const-ness
is not part of a group-declaration.
The check allows to control multiple facets of adding `const`, e.g. if pointers themself should be
marked as `const` if they are not changed.
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D54943
Detect template specializations that should be handled specially.
In some cases it is allowed to extend the `std` namespace with
template specializations.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D129353
In case of a variable with a built-in boolean type, `false` is a better fit to default-initialize it.
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D129420
new clang-tidy checker for assignments within the condition clause of an 'if' statement.
Reviewed By: gribozavr2
Differential Revision: https://reviews.llvm.org/D127114
The clang-tidy check bugprone-branch-clone has a false positive if some
symbols are undefined. This patch silences the warning when the two
sides of a branch are invalid.
Fixes#56057
Differential Revision: https://reviews.llvm.org/D128402
The current way to specify CheckOptions is pretty verbose and unintuitive.
Given that the options are a dictionary it makes much more sense to treat them as such in the config files.
Example:
```
CheckOptions: {SomeCheck.Option: true, SomeCheck.OtherOption: 'ignore'}
# Or
CheckOptions:
SomeCheck.Option: true
SomeCheck.OtherOption: 'ignore'
```
This change will still handle the old syntax with no issue, ensuring we don't screw up users current config files.
The only observable differences are support for the new syntax and `-dump=config` will emit using the new syntax.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D128337
Adds a `-verify-config` command line argument, that when specified will verify the Checks and CheckOptions fields in the config files:
- A warning will be raised for any check that doesn't correspond to a registered check, a suggestion will also be emitted for close misses.
- A warning will be raised for any check glob(containing *) that doesn't match any registered check.
- A warning will be raised for any CheckOption that isn't read by any registered check, a suggestion will also be emitted for close misses.
This can be useful if debuging why a certain check isn't enabled, or the options are being handled as you expect them to be.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D127446
The documentation files were reorganized into subdirectories, but a new
check was added concurrently and wasn't rebased correctly before
submitting. Sort the new clang-tidy checks by check name and fix the
indentation of bugprone-unchecked-optional-access.
The misc-unused-parameters check would trigger false positive warnings
about the parameter being unused when the parameter declaration was
invalid. No longer issue the warning in that case on the assumption
that most parameters are used in practice, so the extra diagnostic is
most likely a false positive.
Fixes#56152
There was a copy-paste mistake at the embedded link:
`clang-tidy/checks/cppcoreguidelines-virtual-class-destructor`
->
`clang-tidy/checks/cppcoreguidelines/virtual-class-destructor`
Sphinx error:
/home/zbebnal/git/llvm-project/clang-tools-extra/docs/ReleaseNotes.rst:168:unknown document: clang-tidy/checks/cppcoreguidelines-virtual-class-destructor
Build bot: https://lab.llvm.org/buildbot#builders/115/builds/29805
Differential Revision: https://reviews.llvm.org/D126891
The `cppcoreguidelines-virtual-class-destructor` supposed to enforce
http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c35-a-base-class-destructor-should-be-either-public-and-virtual-or-protected-and-non-virtual
Quote:
> A **base** class destructor should be either public and virtual, or
> protected and non-virtual
[emphasis mine]
However, this check still rules the following case:
class MostDerived final : public Base {
public:
MostDerived() = default;
~MostDerived() = default;
void func() final;
};
Even though `MostDerived` class is marked `final`, thus it should not be
considered as a **base** class. Consequently, the rule is satisfied, yet
the check still flags this code.
In this patch, I'm proposing to ignore `final` classes since they cannot
be //base// classes.
Reviewed By: whisperity
Differential Revision: https://reviews.llvm.org/D126891
- 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
This reverts commit b94db7ed7e.
See comments on https://reviews.llvm.org/D112916:
- breaks `check-clangd`, and makes clang-tidy crash on simple inputs
- likely does the wrong thing in cross builds
Also revert follow-up "[gn build] (manually) port b94db7ed7e (Confusables.inc)"
This reverts commit 180bae08a0.
The HashLoc in InclusionDirective callback is an unused parameter.
Since pp-trace is also used as a test of Clang’s PPCallbacks interface,
add it to the output of pp-trace could avoid some unintended change on
it.
This shuold resolves PR52673
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D125373
Previously, we were treating a move in the lambda capture as if it happened
within the body of the lambda, not within the function that defines the lambda.
This fixes the same bug as https://reviews.llvm.org/D119165 (which it appears
may have been abandoned by the author?) but does so more simply.
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D126780
The checker missed a check for parameter type of primary template of specialization template and this could cause build breakages.
Reviewed By: aaron.ballman, flx
Differential Revision: https://reviews.llvm.org/D116593
5da7c04 introduced a regression in the NOLINT macro checking loop, replacing the
call to `getImmediateExpansionRange().getBegin()` with
`getImmediateMacroCallerLoc()`, which has similar but subtly different
behaviour.
The consequence is that NOLINTs cannot suppress diagnostics when they are
attached to a token that came from a macro **argument**, rather than elsewhere
in the macro expansion.
Revert to pre-patch behaviour and add test cases to cover this issue.
Differential Revision: https://reviews.llvm.org/D126138
Unfortunately, we must restrict the checker to warn for deprecated headers
only if the header is included directly from a c++ source file.
For header files, we cannot know if the project has a C source file
that also directly/indirectly includes the offending header file
otherwise. Thus, it's better to be on the safe side and suppress those
reports.
One can opt-in the old behavior, emitting diagnostics into header files,
if one explicitly sets the WarnIntoHeaders=true, in which case nothing
will be changed.
Reviewed By: LegalizeAdulthood
Differential Revision: https://reviews.llvm.org/D125769
This partially reverts commit e8cae48702.
Changes since that commit:
- Use `SourceManager::isBeforeInTranslationUnit` instead of the fancy
decomposed decl logarithmic search.
- Add a test for including a system header containing a deprecated
include.
- Add `REQUIRES: system-linux` clause to the test.
Reviewed By: LegalizeAdulthood, whisperity
Differential Revision: https://reviews.llvm.org/D125209
The check should not report includes wrapped by `extern "C" { ... }` blocks,
such as:
```lang=C++
#ifdef __cplusplus
extern "C" {
#endif
#include "assert.h"
#ifdef __cplusplus
}
#endif
```
This pattern comes up sometimes in header files designed to be consumed
by both C and C++ source files.
The check now reports false reports when the header file is consumed by
a C++ translation unit.
In this change, I'm not emitting the reports immediately from the
`PPCallback`, rather aggregating them for further processing.
After all preprocessing is done, the matcher will be called on the
`TranslationUnitDecl`, ensuring that the check callback is called only
once.
Within that callback, I'm recursively visiting each decls, looking for
`LinkageSpecDecls` which represent the `extern "C"` specifier.
After this, I'm dropping all the reports coming from inside of it.
After the visitation is done, I'm emitting the reports I'm left with.
For performance reasons, I'm sorting the `IncludeMarkers` by their
corresponding locations.
This makes the scan `O(log(N)` when looking up the `IncludeMarkers`
affected by the given `extern "C"` block. For this, I'm using
`lower_bound()` and `upper_bound()`.
Reviewed By: whisperity
Differential Revision: https://reviews.llvm.org/D125209
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
The routine that facilitated symbols to be explicitly allowed asked
the name of the called function, which resulted in a crash when the
check was accidentally run on non-trivial C++ code.
Differential Revision: http://reviews.llvm.org/D123992
Reviewed By: aaron.ballman
Adds a flag to `ClangTidyContext` that is used to indicate to checks that fixes will only be applied one at a time.
This is to indicate to checks that each fix emitted should not depend on any other fixes emitted across the translation unit.
I've currently implemented the `IncludeInserter`, `LoopConvertCheck` and `PreferMemberInitializerCheck` to use these support these modes.
Reasoning behind this is in use cases like `clangd` it's only possible to apply one fix at a time.
For include inserter checks, the include is only added once for the first diagnostic that requires it, this will result in subsequent fixes not having the included needed.
A similar issue is seen in the `PreferMemberInitializerCheck` where the `:` will only be added for the first member that needs fixing.
Fixes emitted in `StandaloneDiagsMode` will likely result in malformed code if they are applied all together, conversely fixes currently emitted may result in malformed code if they are applied one at a time.
For this reason invoking `clang-tidy` from the binary will always with `StandaloneDiagsMode` disabled, However using it as a library its possible to select the mode you wish to use, `clangd` always selects `StandaloneDiagsMode`.
This is an example of the current behaviour failing
```lang=c++
struct Foo {
int A, B;
Foo(int D, int E) {
A = D;
B = E; // Fix Here
}
};
```
Incorrectly transformed to:
```lang=c++
struct Foo {
int A, B;
Foo(int D, int E), B(E) {
A = D;
// Fix Here
}
};
```
In `StandaloneDiagsMode`, it gets transformed to:
```lang=c++
struct Foo {
int A, B;
Foo(int D, int E) : B(E) {
A = D;
// Fix Here
}
};
```
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D97121
Report use of `std::vector<const T>` (and similar containers of const
elements). These are now allowed in standard C++ due to undefined
`std::allocator<const T>`. They do not compile with libstdc++ or MSVC.
Future libc++ will remove the extension (D120996).
See docs/clang-tidy/checks/portability-std-allocator-const.rst for detail.
I have attempted clean-up in a large code base. Here are some statistics:
* 98% are related to the container `std::vector`, among `deque/forward_list/list/multiset/queue/set/stack/vector`.
* 24% are related to `std::vector<const std::string>`.
* Both `std::vector<const absl::string_view>` and `std::vector<const int>` contribute 2%. The other contributors spread over various class types.
The check can be useful to other large code bases and may serve as an example
for future libc++ strictness improvement.
Note: on MSVC where -fdelayed-template-parsing is the default, the check cannot
catch cases in uninstantiated templates.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D123655
Balázs Kéri