| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
This follows the Static Analyzer's tradition to name checkers after
things in which they find bugs, not after bugs they find.
Differential Revision: https://reviews.llvm.org/D54556
llvm-svn: 348201
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's an old bug that consists in stale references to symbols remaining in the
GDM if they disappear from other program state sections as a result of any
operation that isn't the actual dead symbol collection. The most common example
here is:
FILE *fp = fopen("myfile.txt", "w");
fp = 0; // leak of file descriptor
In this example the leak were not detected previously because the symbol
disappears from the public part of the program state due to evaluating
the assignment. For that reason the checker never receives a notification
that the symbol is dead, and never reports a leak.
This patch not only causes leak false negatives, but also a number of other
problems, including false positives on some checkers.
What's worse, even though the program state contains a finite number of symbols,
the set of symbols that dies is potentially infinite. This means that is
impossible to compute the set of all dead symbols to pass off to the checkers
for cleaning up their part of the GDM.
No longer compute the dead set at all. Disallow iterating over dead symbols.
Disallow querying if any symbols are dead. Remove the API for marking symbols
as dead, as it is no longer necessary. Update checkers accordingly.
Differential Revision: https://reviews.llvm.org/D18860
llvm-svn: 347953
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D52983
llvm-svn: 344017
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D51251
llvm-svn: 340963
|
| |
|
|
|
|
| |
exploration strategy
llvm-svn: 326529
|
| |
|
|
|
|
| |
strategy
llvm-svn: 326518
|
| |
|
|
|
|
|
|
|
|
| |
on coverage
After the investigation it seems safe to flip the switch.
Differential Revision: https://reviews.llvm.org/D43782
llvm-svn: 326157
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Added new enum in order to differentiate the warning messages on "misusing" into
3 categories: function calls, moving an object, copying an object. (At the
moment the checker gives the same message in case of copying and moving.)
Additional test cases added as well.
Differential Revision: https://reviews.llvm.org/D38674
llvm-svn: 316852
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handling method calls on base-class sub-objects
An earlier solution from Artem r315301 solves the reset problem, however, the
reports should be handled the same way in case of method calls. We should not
just report the base class of the object where the method was defined but the
whole object.
Fixed false positive which came from not removing the subobjects in case of a
state-resetting function. (Just replaced the State->remove(...) call to
removeFromState(..) which was defined exactly for that purpose.)
Some minor typos fixed in this patch as well which did not worth a whole new
patch in my opinion, so included them here.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 316850
|
| |
|
|
|
|
|
|
|
|
|
| |
If a method is resetting the state of an object that was moved from, it should
be safe to use this object again. However if the method was defined in a parent
class, but used in a child class, the reset didn't happen from the checker's
perspective.
Differential Revision: https://reviews.llvm.org/D31538
llvm-svn: 315301
|
|
|
The checker currently warns on copying, moving, or calling methods on an object
that was recently std::move'd from. It understands a set of "state reset"
methods that bring a moved-from object back to a well-specified state.
Patch by Peter Szecsi!
Differential Revision: https://reviews.llvm.org/D24246
llvm-svn: 298698
|
