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
The thread safety analysis isn't very useful in ObjC (you can't annotate
ObjC classes or methods) but we can still analyze the actual code and
show violations in usage of C/C++ functions.
Fixes PR19541, which does not use thread safety attributes but crashes
with -Weverything.
llvm-svn: 208436
The assignment needs to be before the destruction of the temporary.
This patch calls out to addStmt, which invokes VisitDeclStmt, which has
all the correct logic for handling temporaries.
llvm-svn: 207985
definition below all of the header #include lines, clang edition.
If you want more details about this, you can see some of the commits to
Debug.h in LLVM recently. This is just the clang section of a cleanup
I've done for all uses of DEBUG_TYPE in LLVM.
llvm-svn: 206849
* Adds an iterator_range interface to CallExpr to get the arguments
* Modifies SExpr such that it must be allocated in the Arena, and cannot be deleted
* Minor const-correctness and nullptr updates
* Adds some operator!= implementations to complement operator==
* Removes unused functionality
llvm-svn: 205915
This patch is the first part of a significant refactoring that seeks to restore
sanity to way thread safety analysis deals with capability expressions. The
current patch merely provides an outline of the structure of the new system.
It's not yet connected to the actual analysis, so there's no change in
functionality.
llvm-svn: 205728
which warns on compound conditionals that always evaluate to the same value.
For instance, (x > 5 && x < 3) will always be false since no value for x can
satisfy both conditions.
This patch also changes the CFG to use these tautological values for better
branch analysis. The test for -Wunreachable-code shows how this change catches
additional dead code.
Patch by Anders Rönnholm.
llvm-svn: 205665
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
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
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 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
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
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
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
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
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
Manuel Klimek