Consider this code:
```
if (Cond) {
#ifdef X_SUPPORTED
X();
#else
return;
#endif
} else {
Y();
}
Z();```
In this example, if `X_SUPPORTED` is not defined, currently we'll get a warning from the else-after-return check. However If we apply that fix, and then the code is recompiled with `X_SUPPORTED` defined, we have inadvertently changed the behaviour of the if statement due to the else being removed. Code flow when `Cond` is `true` will be:
```
X();
Y();
Z();```
where as before the fix it was:
```
X();
Z();```
This patch adds checks that guard against `#endif` directives appearing between the control flow interrupter and the else and not applying the fix if they are detected.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D91485
Added a 'RefactorConditionVariables' option to control how the check handles condition variables
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D82824
Fix a crash in clangd caused by an (admittidly incorrect) Remark diagnositic being emitted from readability-else-after-return.
This crash doesn't occur in clang-tidy so there are no tests there for this.
Reviewed By: hokein
Differential Revision: https://reviews.llvm.org/D81785
Adds a new ASTMatcher condition called 'hasInitStatement()' that matches if,
switch and range-for statements with an initializer. Reworked clang-tidy
readability-else-after-return to handle variables in the if condition or init
statements in c++17 ifs. Also checks if removing the else would affect object
lifetimes in the else branch.
Fixes PR44364.
The readability-else-after-return check should be smarter about cases where the
variable defined in the condition is used in the `else` branch. This patch makes
it just ignore such cases, but alternative solutions may be better (added a
FIXME).
llvm-svn: 351751
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
a stray single '\r' from one file. These are the last line ending issues
I can find in the files containing parts of LLVM's file headers.
llvm-svn: 351634
Summary:
The readability-else-after-return check was not warning about
an else after a throw of an exception that had arguments that needed
to be cleaned up.
Reviewers: aaron.ballman, alexfh, djasper
Reviewed By: aaron.ballman
Subscribers: lebedev.ri, klimek, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D40505
llvm-svn: 319174
Summary:
Fix generated by this check changed program semantics
in the case where 'if' was a part (direct child) of other statement.
Fixes PR30652.
Patch by Paweł Żukowski.
Reviewers: malcolm.parsons, alexfh, djasper
Subscribers: mgehre, omtcyfz, cfe-commits
Differential Revision: https://reviews.llvm.org/D26125
llvm-svn: 285999
`readability-else-after-return` only warns about `return` calls, but LLVM Coding
Standars stat that `throw`, `continue`, `goto`, etc after `return` calls are
bad, too.
Reviwers: alexfh, aaron.ballman
Differential Revision: https://reviews.llvm.org/D23265
llvm-svn: 278257
clang-tidy checks are organized into modules. This refactoring moves the
readability module checks into the namespace clang::tidy::readability
http://reviews.llvm.org/D7997
Patch by Richard Thomson!
llvm-svn: 230946