| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Allow this warning to detect a larger number of constant values, including
negative numbers, and handle non-int types better.
Differential Revision: https://reviews.llvm.org/D66044
llvm-svn: 372448
|
|
|
|
|
|
|
|
|
| |
treat __assume(0) like __builtin_unreachable.
Fixes PR29134.
https://reviews.llvm.org/D43221
llvm-svn: 325052
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 207994
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
'noreturn' function.
llvm-svn: 203333
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 203027
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 202351
|
|
|
|
|
|
| |
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: 201893
|
|
|
|
|
|
|
|
| |
This ports the last Sema tests over to use the frontend directly, and adds a
local lit substitution to disable inappropriate %clang usage under this
directory.
llvm-svn: 199348
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a more natural order of evaluation, and it is very important
for visualization in the static analyzer. Within Xcode, the arrows
will not jump from right to left, which looks very visually jarring.
It also provides a more natural location for dataflow-based diagnostics.
Along the way, we found a case in the analyzer diagnostics where we
needed to indicate that a variable was "captured" by a block.
-fsyntax-only timings on sqlite3.c show no visible performance change,
although this is just one test case.
Fixes <rdar://problem/13016513>
llvm-svn: 174447
|
|
|
|
|
|
| |
Fixes <rdar://problem/11005770>.
llvm-svn: 162545
|
|
|
|
|
|
|
|
| |
Rewording the diagnostic to be more precise/correct: "default label in switch
which covers all enumeration values" and changed the switch to
-Wcovered-switch-default
llvm-svn: 148783
|
|
|
|
|
|
|
|
| |
This is for consistency, since the flag is actually under -Wswitch now, rather
than -Wswitch-enum (since it's really valuable for the former and rather
orthogonal to the latter)
llvm-svn: 148680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This warning acts as the complement to the main -Wswitch-enum warning (which
warns whenever a switch over enum without a default doesn't cover all values of
the enum) & has been an an-doc coding convention in LLVM and Clang in my
experience. The purpose is to ensure there's never a "dead" default in a
switch-over-enum because this would hide future -Wswitch-enum errors.
The name warning has a separate flag name so it can be disabled but it's grouped
under -Wswitch-enum & is on-by-default because of this.
The existing violations of this rule in test cases have had the warning disabled
& I've added a specific test for the new behavior (many negative cases already
exist in the same test file - and none regressed - so I didn't add more).
Reviewed by Ted Kremenek ( http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120116/051690.html )
llvm-svn: 148640
|
|
|
|
| |
llvm-svn: 147479
|
|
|
|
|
|
| |
should suppress false positives resulting from 'assert' and friends.
llvm-svn: 138576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crawl.
This is accomplished by forcing the needed expressions for -Wuninitialized to always be CFGElements in the CFG.
This allows us to remove a fair amount of the code for -Wuninitialized.
Some fallout:
- AnalysisBasedWarnings.cpp now specifically toggles the CFGBuilder to create a CFG that is suitable for -Wuninitialized. This
is a layering violation, since the logic for -Wuninitialized is in libAnalysis. This can be fixed with the proper refactoring.
- Some of the source locations for -Wunreachable-code warnings have shifted. While not ideal, this is okay because that analysis
already needs some serious reworking.
llvm-svn: 135480
|
|
|
|
|
|
|
|
| |
in code generated with the compiler,
- Fixed test cases for unreachable code warnings produced by Sema.
llvm-svn: 117220
|
|
|
|
|
|
|
|
| |
statement live if a switch on an enum value has
explicit 'case:' statements for each enum value.
llvm-svn: 113451
|
|
|
|
|
|
|
|
|
| |
type" warning.
The rationale behind this is that it is normal for callback functions to have a non-void return type
and it should still be possible to mark them noreturn. (JavaScriptCore is a good example of this).
llvm-svn: 112918
|
|
|
|
|
|
| |
non-void result. (<rdar://problem/7562925>)
llvm-svn: 111492
|
|
|
|
|
|
| |
analysis needs this.
llvm-svn: 97014
|
|
|
|
|
|
| |
dead array references.
llvm-svn: 94115
|
|
|
|
| |
llvm-svn: 94094
|
|
|
|
| |
llvm-svn: 94093
|
|
|
|
|
|
| |
assignments.
llvm-svn: 94086
|
|
|
|
|
|
| |
unary operators.
llvm-svn: 94084
|
|
|
|
| |
llvm-svn: 93584
|
|
|
|
| |
llvm-svn: 93574
|
|
llvm-svn: 93503
|