aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Analysis/ReachableCode.cpp
AgeCommit message (Collapse)AuthorFilesLines
2017-04-11Fix PR13910: Don't warn that __builtin_unreachable() is unreachableAlex Lorenz1-2/+9
Differential Revision: https://reviews.llvm.org/D25321 llvm-svn: 299951
2017-04-05-Wunreachable-code: 'true' and 'false' should not be treated as configurationAlex Lorenz1-1/+7
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
2017-01-12Avoid multiple -Wunreachable-code diagnostics that are triggered byAlex Lorenz1-5/+15
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
2016-11-01[ReachableCode] Skip over ExprWithCleanups in isConfigurationValueTim Shen1-0/+2
Summary: Fixes pr29152. Reviewers: rsmith, pirama, krememek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D24010 llvm-svn: 285657
2015-06-22Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko1-3/+2
llvm-svn: 240353
2015-06-22Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko1-2/+3
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
2015-01-14[cleanup] Re-sort *all* #include lines with llvm/utils/sort_includes.pyChandler Carruth1-2/+2
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
2014-05-23Make dead return statement detection more robust against changes in the CFG.Manuel Klimek1-21/+46
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
2014-05-20[C++11] Use 'nullptr'. Analysis edition.Craig Topper1-2/+2
llvm-svn: 209191
2014-04-16-Wunreachable-code: refine recognition of unreachable "sigil" to cope with ↵Ted Kremenek1-1/+4
implicit casts in C++. Fixes <rdar://problem/16631033>. llvm-svn: 206360
2014-03-29[-Wunreachable-code] Expand paren-suppression heuristic to C++/ObjC bools.Ted Kremenek1-6/+11
llvm-svn: 205074
2014-03-29Improve -Wunreachable-code to provide a means to indicate code is ↵Ted Kremenek1-14/+48
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
2014-03-21[-Wunreachable-code] add a specialized diagnostic for unreachable increment ↵Ted Kremenek1-0/+20
expressions of loops. llvm-svn: 204430
2014-03-20[-Wunreachable-code] Tweak isTrivialDoWhile() to handle implicit casts.Ted Kremenek1-1/+1
llvm-svn: 204376
2014-03-20[-Wunreachable-code] Look through member accesses for 'static const bool' ↵Ted Kremenek1-23/+27
configuration values. llvm-svn: 204315
2014-03-20[-Wunreachable-code] constexpr functions can be used as configuration values.Ted Kremenek1-0/+5
llvm-svn: 204308
2014-03-20[-Wunreachable-code] Simplify and broad -Wunreachable-code-return, including ↵Ted Kremenek1-72/+22
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
2014-03-15Remove dead functions from unreachable code analysis.Benjamin Kramer1-44/+0
llvm-svn: 204004
2014-03-15-Wunreachable-code: treat 'const bool' locals as control values.Ted Kremenek1-1/+6
llvm-svn: 204001
2014-03-15Further refine -Wunreachable-code groups so that -Wno-unreachable-code-break ↵Ted Kremenek1-34/+27
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
2014-03-15Start breaking -Wunreachable-code up into different diagnostic groups.Ted Kremenek1-22/+40
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
2014-03-09[-Wunreachable-code] Handle Objective-C bool literals in 'isConfigurationValue'.Ted Kremenek1-24/+63
This includes special casing 'YES' and 'NO', which are constants defined as macros. llvm-svn: 203380
2014-03-08[-Wunreachable-code] Tweak heuristic for configuration values to include ↵Ted Kremenek1-6/+11
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
2014-03-08[-Wunreachabe-code] Don't warn about unreachable destructors for temporaries.Ted Kremenek1-3/+5
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
2014-03-08[-Wunreachable-code] Handle 'return' with no argument dominated by ↵Ted Kremenek1-6/+11
'noreturn' function. llvm-svn: 203333
2014-03-07[C++11] Revert uses of lambdas with array_pod_sort.Benjamin Kramer1-7/+10
Looks like GCC implements the lambda->function pointer conversion differently. llvm-svn: 203293
2014-03-07[C++11] Convert sort predicates into lambdas.Benjamin Kramer1-10/+7
No functionality change. llvm-svn: 203289
2014-03-07[-Wunreachable-code] Treat constant globals as configuration values in ↵Ted Kremenek1-2/+14
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
2014-03-07Fix recent regressions in -Wreturn-type caused by heuristics to ↵Ted Kremenek1-248/+274
-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
2014-03-07[-Wunreachable-code] Correctly expand artificial reachability to pruned '&&' ↵Ted Kremenek1-4/+12
and '||' branches involving configuration values. llvm-svn: 203194
2014-03-07[-Wunreachable-code] Teach reachable code analysis heuristics about more ↵Ted Kremenek1-0/+2
literal types. llvm-svn: 203193
2014-03-06[-Wunreachable-code] Refine treating all branches of 'switch' as reachable, ↵Ted Kremenek1-18/+4
which includes those with all cases covered but with no 'default:'. llvm-svn: 203094
2014-03-06[-Wunreachable-code] don't warn about dead 'return <string literal>' ↵Ted Kremenek1-2/+52
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
2014-03-06[-Wunreachable-code] Handle idiomatic do...while() with an uninteresting ↵Ted Kremenek1-7/+4
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
2014-03-06[-Wunreachable-code] Handle idiomatic do...while() with an uninteresting ↵Ted Kremenek1-7/+17
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
2014-03-05[-Wunreachable-code] generalize pruning out warning on trivial returns.Ted Kremenek1-9/+6
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
2014-03-05[-Wunreachable-code] include some enum constants in "configuration value" ↵Ted Kremenek1-0/+5
heuristic llvm-svn: 203026
2014-03-05[-Wunreachable-code] generalize configuration value checking to all ↵Ted Kremenek1-1/+1
comparison operators. llvm-svn: 203016
2014-03-05[-Wunreachable-code] Don't warn about dead code guarded by a "configuration ↵Ted Kremenek1-9/+73
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
2014-03-04[-Wunreachable-code] handle cases where a dead 'return' may have a valid ↵Ted Kremenek1-0/+5
predecessor. Fies PR19040. llvm-svn: 202892
2014-02-27[-Wunreachable-code] always treat 'case:' and 'default:' cases as reachable.Ted Kremenek1-8/+27
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
2014-02-27[-Wunreachable-code] Don't warn about trivially unreachable return ↵Ted Kremenek1-4/+57
statements preceded by 'noreturn' functions. llvm-svn: 202352
2014-02-27[-Wunreachable-code] Don't warn about unreachable 'default:' cases.Ted Kremenek1-0/+6
They are covered by -Wcovered-switch-default. llvm-svn: 202349
2014-02-27[-Wunreachable-code] Prune out unreachable warnings where a 'break' is ↵Ted Kremenek1-7/+43
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
2013-09-22Make sort predicate match the qsort convention.Benjamin Kramer1-1/+5
llvm-svn: 191177
2013-09-22Fix array_pod_sort predicates after LLVM change.Benjamin Kramer1-4/+3
llvm-svn: 191176
2013-08-15Properly track l-paren of a CXXFucntionalCastExpr.Eli Friedman1-1/+1
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
2013-02-23Remove the CFGElement "Invalid" state.David Blaikie1-2/+2
Use Optional<CFG*> where invalid states were needed previously. In the one case where that's not possible (beginAutomaticObjDtorsInsert) just use a dummy CFGAutomaticObjDtor. Thanks for the help from Jordan Rose & discussion/feedback from Ted Kremenek and Doug Gregor. Post commit code review feedback on r175796 by Ted Kremenek. llvm-svn: 175938
2013-02-21Replace CFGElement llvm::cast support to be well-defined.David Blaikie1-2/+2
See r175462 for another example/more details. llvm-svn: 175796
2013-01-12Remove useless 'llvm::' qualifier from names like StringRef and others that areDmitri Gribenko1-2/+2
brought into 'clang' namespace by clang/Basic/LLVM.h llvm-svn: 172323
generated by cgit v1.1 at 2025-10-11 20:20:54 +0000