These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
With this PR, `bugprone-assert-side-effect` reports non-const calls to
`<<` and `>>` operators and does no longer consider any const operator
calls to have side effects.
E.g. the following snippet is now reported and was previously not:
```
std::stringstream ss;
assert(ss << 1);
```
The following snippet was previously a false-positive and is not
reported anymore:
```
struct {
int operator+=(int i) const { return i; }
} t;
assert(t += 1);
```
Some time ago a patch was merged to disable all clang-tidy warnings
from system macros. This led to bugprone-assert-side-effect
silently no longer working, since the warnings came from a system
macro. The problem was not detected because the fake assert functions
were implemented in the same file as the test, instead of being a
system include like it's done in the real world.
Move the assert to a proper system header, and fix the code to
warn at the correct location.
This patch is breakdown from https://reviews.llvm.org/D147081
by PiotrZSL.
Fixes https://github.com/llvm/llvm-project/issues/62314
Differential Revision: https://reviews.llvm.org/D150071
There's many instances in clang tidy checks where owning strings are used when we already have a stable string from the options, so using a StringRef makes much more sense.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124341
A semicolon-separated list of the names of functions or methods to be considered as not having side-effects was added for bugprone-assert-side-effect. It can be used to exclude methods like iterator::begin/end from being considered as having side-effects.
Differential Revision: https://reviews.llvm.org/D116478
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