| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}
llvm-svn: 338291
|
|
|
|
|
|
|
|
|
| |
treat __assume(0) like __builtin_unreachable.
Fixes PR29134.
https://reviews.llvm.org/D43221
llvm-svn: 325052
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation is in AnalysisDeclContext.cpp and the class is called
AnalysisDeclContext.
Making those match up has numerous benefits, including:
- Easier jump from header to/from implementation.
- Easily identify filename from class.
Differential Revision: https://reviews.llvm.org/D37500
llvm-svn: 312671
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25321
llvm-svn: 299951
|
|
|
|
|
|
|
|
|
| |
macros
Clang should emit -Wunreachable-code warnings in C mode for code that's
unreachable because of a 'false' or '!true' condition.
llvm-svn: 299541
|
|
|
|
|
|
|
|
|
|
|
| |
the same source range and use the unary operator fixit only when it
actually silences the warning.
rdar://24570531
Differential Revision: https://reviews.llvm.org/D28231
llvm-svn: 291757
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes pr29152.
Reviewers: rsmith, pirama, krememek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24010
llvm-svn: 285657
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
|
|
|
|
|
|
| |
Sorry for the noise, I managed to miss a bunch of recent regressions of
include orderings here. This should actually sort all the includes for
Clang. Again, no functionality changed, this is just a mechanical
cleanup that I try to run periodically to keep the #include lines as
regular as possible across the project.
llvm-svn: 225979
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is a precondition to the proposed change to handle temporary
dtors correctly.
The idea is to explicitly search for the next return that doesn't have other
paths into it (that is, if the current block is dead, the block containing the
return must be dead, too). Thus, introducing non-control-flow block
transitions will not break the logic.
llvm-svn: 209531
|
|
|
|
| |
llvm-svn: 209191
|
|
|
|
|
|
|
|
| |
implicit casts in C++.
Fixes <rdar://problem/16631033>.
llvm-svn: 206360
|
|
|
|
| |
llvm-svn: 205074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intentionally marked dead via if((0)).
Taking a hint from -Wparentheses, use an extra '()' as a sigil that
a dead condition is intentionally dead. For example:
if ((0)) { dead }
When this sigil is found, do not emit a dead code warning. When the
analysis sees:
if (0)
it suggests inserting '()' as a Fix-It.
llvm-svn: 205069
|
|
|
|
|
|
| |
expressions of loops.
llvm-svn: 204430
|
|
|
|
| |
llvm-svn: 204376
|
|
|
|
|
|
| |
configuration values.
llvm-svn: 204315
|
|
|
|
| |
llvm-svn: 204308
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nontrivial returns.
The exception is return statements that include control-flow,
which are clearly doing something "interesting".
99% of the cases I examined for -Wunreachable-code that fired
on return statements were not interesting enough to warrant
being in -Wunreachable-code by default. Thus the move to
include them in -Wunreachable-code-return.
This simplifies a bunch of logic, including removing the ad hoc
logic to look for std::string literals.
llvm-svn: 204307
|
|
|
|
| |
llvm-svn: 204004
|
|
|
|
| |
llvm-svn: 204001
|
|
|
|
|
|
|
|
|
|
| |
doesn't turn off all unreachable code warnings.
Also relax unreachable 'break' and 'return' to not check for being
preceded by a call to 'noreturn'. That turns out to not be so
interesting in practice.
llvm-svn: 204000
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recent work on -Wunreachable-code has focused on suppressing uninteresting
unreachable code that center around "configuration values", but
there are still some set of cases that are sometimes interesting
or uninteresting depending on the codebase. For example, a dead
"break" statement may not be interesting for a particular codebase,
potentially because it is auto-generated or simply because code
is written defensively.
To address these workflow differences, -Wunreachable-code is now
broken into several diagnostic groups:
-Wunreachable-code: intended to be a reasonable "default" for
most users.
and then other groups that turn on more aggressive checking:
-Wunreachable-code-break: warn about dead break statements
-Wunreachable-code-trivial-return: warn about dead return statements
that return "trivial" values (e.g., return 0). Other return
statements that return non-trivial values are still reported
under -Wunreachable-code (this is an area subject to more refinement).
-Wunreachable-code-aggressive: supergroup that enables all these
groups.
The goal is to eventually make -Wunreachable-code good enough to
either be in -Wall or on-by-default, thus finessing these warnings
into different groups helps achieve maximum signal for more users.
TODO: the tests need to be updated to reflect this extra control
via diagnostic flags.
llvm-svn: 203994
|
|
|
|
|
|
|
| |
This includes special casing 'YES' and 'NO', which are constants
defined as macros.
llvm-svn: 203380
|
|
|
|
|
|
|
|
|
| |
arithmetic operations involving sizeof(), but not raw integers.
This case was motivated by a false positive with the
llvm::AlignOf<> specialization in LLVM.
llvm-svn: 203363
|
|
|
|
|
|
|
|
| |
This can possibly be refined later, but right now the experience
is so incomprehensible for a user to understand what is going on
this isn't a useful warning.
llvm-svn: 203336
|
|
|
|
|
|
| |
'noreturn' function.
llvm-svn: 203333
|
|
|
|
|
|
| |
Looks like GCC implements the lambda->function pointer conversion differently.
llvm-svn: 203293
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 203289
|
|
|
|
|
|
|
|
|
| |
unreachable code heuristics.
This one could possibly be refined even further; e.g. looking
at the initializer and see if it is truly a configuration value.
llvm-svn: 203283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Wunreachable-code.
I had forgotten that the same reachability code is used by both -Wreturn-type
and -Wunreachable-code, so the heuristics applied to the latter were indirectly
impacting the former.
To address this, the reachability code is more refactored so that whiled
the logic at its core is shared, the intention of the clients are better
captured and segregated in helper APIs.
Fixes PR19074, and also some false positives reported offline to me
by Nick Lewycky.
llvm-svn: 203209
|
|
|
|
|
|
| |
and '||' branches involving configuration values.
llvm-svn: 203194
|
|
|
|
|
|
| |
literal types.
llvm-svn: 203193
|
|
|
|
|
|
| |
which includes those with all cases covered but with no 'default:'.
llvm-svn: 203094
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dominated by a 'noreturn' call, where literal becomes an std::string.
I have mixed feelings about this one. It's used all over the codebase,
and is analogous to the current heuristic for ordinary C string literals.
This requires some ad hoc pattern matching of the AST. While the
test case mirrors what we see std::string in libc++, it's not really
testing the libc++ headers.
llvm-svn: 203091
|
|
|
|
|
|
|
|
|
|
| |
condition.
Sometimes do..while() is used to create a scope that can be left early.
In such cases, the unreachable 'while()' test is not usually interesting
unless it actually does something that is observable.
llvm-svn: 203051
|
|
|
|
|
|
|
|
|
|
| |
condition.
Sometimes do..while() is used to create a scope that can be left early.
In such cases, the unreachable 'while()' test is not usually interesting
unless it actually does something that is observable.
llvm-svn: 203036
|
|
|
|
|
|
|
|
| |
Previously we only pruned dead returns preceded by a call to a
'noreturn' function. After looking at the results of the LLVM codebase,
there are many others that should be pruned as well.
llvm-svn: 203029
|
|
|
|
|
|
| |
heuristic
llvm-svn: 203026
|
|
|
|
|
|
| |
comparison operators.
llvm-svn: 203016
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value".
Some unreachable code is only "sometimes unreachable" because it
is guarded by a configuration value that is determined at compile
time and is always constant. Sometimes those represent real bugs,
but often they do not. This patch causes the reachability analysis
to cover such branches even if they are technically unreachable
in the CFG itself. There are some conservative heuristics at
play here to determine a "configuration value"; these are intended
to be refined over time.
llvm-svn: 202912
|
|
|
|
|
|
|
|
| |
predecessor.
Fies PR19040.
llvm-svn: 202892
|
|
|
|
|
|
|
|
|
|
|
| |
This is a heuristic. Many switch statements, although they look covered
over an enum, may actually handle at runtime more values than in the enum.
This is overly conservative, as there are some cases that clearly
can be ruled as being clearly unreachable, e.g. 'switch (42) { case 1: ... }'.
We can refine this later.
llvm-svn: 202436
|
|
|
|
|
|
| |
statements preceded by 'noreturn' functions.
llvm-svn: 202352
|
|
|
|
|
|
| |
They are covered by -Wcovered-switch-default.
llvm-svn: 202349
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
preceded by a call to a 'noreturn' function.
For example:
unreachable();
break;
This code is idiomatic and defensive. The fact that 'break' is
unreachable here is not interesting. This occurs frequently
in LLVM/Clang itself.
llvm-svn: 202328
|
|
|
|
| |
llvm-svn: 191177
|
|
|
|
| |
llvm-svn: 191176
|
|
|
|
|
|
|
|
|
|
| |
In addition to storing more useful information in the AST, this
fixes a semantic check in template instantiation which checks whether
the l-paren location is valid.
Fixes PR16903.
llvm-svn: 188495
|