It was previously reverted by 8406839d19.
---
This flag was introduced by
6818991d71
commit 6818991d71
Author: Ted Kremenek <kremenek@apple.com>
Date: Mon Dec 7 22:06:12 2009 +0000
Add clang-cc option '-analyzer-opt-analyze-nested-blocks' to treat
block literals as an entry point for analyzer checks.
The last reference was removed by this commit:
5c32dfc5fb
commit 5c32dfc5fb
Author: Anna Zaks <ganna@apple.com>
Date: Fri Dec 21 01:19:15 2012 +0000
[analyzer] Add blocks and ObjC messages to the call graph.
This paves the road for constructing a better function dependency graph.
If we analyze a function before the functions it calls and inlines,
there is more opportunity for optimization.
Note, we add call edges to the called methods that correspond to
function definitions (declarations with bodies).
Consequently, we should remove this dead flag.
However, this arises a couple of burning questions.
- Should the `cc1` frontend still accept this flag - to keep
tools/users passing this flag directly to `cc1` (which is unsupported,
unadvertised) working.
- If we should remain backward compatible, how long?
- How can we get rid of deprecated and obsolete flags at some point?
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D126067
This flag was introduced by
6818991d71
commit 6818991d71
Author: Ted Kremenek <kremenek@apple.com>
Date: Mon Dec 7 22:06:12 2009 +0000
Add clang-cc option '-analyzer-opt-analyze-nested-blocks' to treat
block literals as an entry point for analyzer checks.
The last reference was removed by this commit:
5c32dfc5fb
commit 5c32dfc5fb
Author: Anna Zaks <ganna@apple.com>
Date: Fri Dec 21 01:19:15 2012 +0000
[analyzer] Add blocks and ObjC messages to the call graph.
This paves the road for constructing a better function dependency graph.
If we analyze a function before the functions it calls and inlines,
there is more opportunity for optimization.
Note, we add call edges to the called methods that correspond to
function definitions (declarations with bodies).
Consequently, we should remove this dead flag.
However, this arises a couple of burning questions.
- Should the `cc1` frontend still accept this flag - to keep
tools/users passing this flag directly to `cc1` (which is unsupported,
unadvertised) working.
- If we should remain backward compatible, how long?
- How can we get rid of deprecated and obsolete flags at some point?
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D126067
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,
void func();
becomes
void func(void);
This is the ninth batch of tests being updated (there are a
significant number of other tests left to be updated).
In macros, 'do {...} while (0)' is often used. Don't warn about the condition 0 when it is unreachable.
Differential Revision: https://reviews.llvm.org/D25606
llvm-svn: 284477
Returns when calling an inline function should not be merged in the ExplodedGraph unless they are same.
Differential Revision: https://reviews.llvm.org/D25326
llvm-svn: 283554
When there is 'do { } while (0);' in the code the ExplodedGraph and UnoptimizedCFG did not match.
Differential Revision: https://reviews.llvm.org/D24759
llvm-svn: 283095
Example:
switch (x) {
int a; // <- This is unreachable but needed
case 1:
a = ...
Differential Revision: https://reviews.llvm.org/D24905
llvm-svn: 282574
This is still an alpha checker, but we use it in certain tests to make sure
something is not being executed.
This should fix the buildbots.
llvm-svn: 188682
They cooperate in that NSErrorChecker listens for ImplicitNullDerefEvent events that
DereferenceChecker can dispatch.
ImplicitNullDerefEvent is when we dereferenced a location that may be null.
llvm-svn: 126659
CStringChecker
ChrootChecker
MallocChecker
PthreadLockChecker
StreamChecker
UnreachableCodeChecker
MallocChecker creates implicit dependencies between checkers and needs to be handled differently.
llvm-svn: 125598
- Fixed some iterator style issues
- Don't process blocks that have been visited already
- Fixed a case where a unreachable block cycle was not reported
- Minor test case changes
- Added one test case from flow-sensitive version of the check. More coming.
llvm-svn: 115861
- Allowed reporting of dead macros
- Added path walking function to search for false positives in conditional statements
- Updated some affected tests
- Added some false positive test cases
llvm-svn: 109561
- Created a new class to do post-analysis
- Updated several test cases with unreachable code to expect a warning
- Added some general tests
llvm-svn: 109286
Balazs Benics