| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
rdar://46357478
rdar://47121327
Differential Revision: https://reviews.llvm.org/D56240
llvm-svn: 350982
|
| |
|
|
|
|
| |
The error must have crept during the cherry-pick.
llvm-svn: 350870
|
| |
|
|
|
|
|
|
|
|
| |
..now that it includes OSObjects
rdar://46509986
Differential Revision: https://reviews.llvm.org/D56404
llvm-svn: 350869
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D56402
llvm-svn: 350868
|
| |
|
|
|
|
|
|
| |
for readability
Differential Revision: https://reviews.llvm.org/D56344
llvm-svn: 350867
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The complicated machinery for passing the summary log around is actually
only used for one thing! To figure out whether the "dealloc" message was
sent.
Since I have tried to extend it for other uses and failed (it's actually
very hard to use), I think it's much better to simply use a tag and
remove the summary log altogether.
Differential Revision: https://reviews.llvm.org/D56228
llvm-svn: 350864
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D56071
llvm-svn: 350860
|
| |
|
|
|
|
|
|
| |
the object type is already communicated by a separate field
Differential Revision: https://reviews.llvm.org/D56070
llvm-svn: 350859
|
| |
|
|
|
|
|
|
| |
This would be needed in the future.
https://reviews.llvm.org/D56040
llvm-svn: 350858
|
| |
|
|
|
|
|
|
|
|
| |
RetainSummaryManager.
Allows using it in future outside of RetEffect.
Differential Revision: https://reviews.llvm.org/D56039
llvm-svn: 350857
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is a different approach to landing the reverted r349701.
It is expected to have the same object (memory region) treated as if it has
different types in different program points. The correct behavior for
RegionStore when an object is stored as an object of type T1 but loaded as
an object of type T2 is to store the object as if it has type T1 but cast it
to T2 during load.
Note that the cast here is some sort of a "reinterpret_cast" (even in C). For
instance, if you store an integer and load a float, you won't get your integer
represented as a float; instead, you will get garbage.
Admit that we cannot perform the cast and return an unknown value.
Differential Revision: https://reviews.llvm.org/D55875
rdar://problem/45062567
llvm-svn: 349984
|
| |
|
|
|
|
|
|
|
|
| |
RetainCountChecker on type mismatch even for inlined functions"
This reverts commit b44b33f6e020a2c369da2b0c1d53cd52975f2526.
Revert the revert with the fix.
llvm-svn: 349939
|
| |
|
|
|
|
|
|
| |
checker
It should be in the past tense.
llvm-svn: 349938
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
RetainCountChecker on type mismatch even for inlined functions
The fix done in D55465 did not previously apply when the function was inlined.
rdar://46889541
Differential Revision: https://reviews.llvm.org/D55976
........
Fixes broken buildbot: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/14764
llvm-svn: 349894
|
| |
|
|
|
|
|
|
|
|
|
|
| |
inlined functions
The fix done in D55465 did not previously apply when the function was inlined.
rdar://46889541
Differential Revision: https://reviews.llvm.org/D55976
llvm-svn: 349876
|
| |
|
|
|
|
|
|
|
|
|
|
| |
mismatched summary in inlined functions
Previously, we were not printing a note at all if at least one of the parameters was not annotated.
rdar://46888422
Differential Revision: https://reviews.llvm.org/D55972
llvm-svn: 349875
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Replace multiple comparisons of getOS() value with FreeBSD, NetBSD,
OpenBSD and DragonFly with matching isOS*BSD() methods. This should
improve the consistency of coding style without changing the behavior.
Direct getOS() comparisons were left whenever used in switch or switch-
like context.
Differential Revision: https://reviews.llvm.org/D55916
llvm-svn: 349752
|
| |
|
|
|
|
|
|
| |
Patch by Gábor Borsik!
Differential Revision: https://reviews.llvm.org/D54918
llvm-svn: 349698
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that it's not all that uncommon to have a C++ override of, say,
memcpy that receives a structure (or two) by reference (or by value, if it's
being copied from) and copies memory from it (or into it, if it's passed
by reference). In this case the argument will be of structure type (recall that
expressions of reference type do not exist: instead, C++ classifies expressions
into prvalues and lvalues and xvalues).
In this scenario we crash because we are trying to assume that, say,
a memory region is equal to an empty CompoundValue (the non-lazy one; this is
what makeZeroVal() return for compound types and it represents prvalue of
an object that is initialized with an empty initializer list).
Add defensive checks.
Differential Revision: https://reviews.llvm.org/D55873
rdar://problem/45366551
llvm-svn: 349682
|
| |
|
|
|
|
|
|
|
| |
The warning seems spurious (GCC bug 51242), but the bit field is
simply not worth the hassle.
rdar://problem/41349073
llvm-svn: 349394
|
| |
|
|
|
|
|
|
|
|
| |
functions'
Accidentally commited earlier with the same commit title, but really it
should've been
"Revert rC349283 '[analyzer][MallocChecker] Improve warning messages on double-delete errors'"
llvm-svn: 349344
|
| |
|
|
|
|
| |
functions'
llvm-svn: 349340
|
| |
|
|
| |
llvm-svn: 349336
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-using a moved-from local variable is most likely a bug because there's
rarely a good motivation for not introducing a separate variable instead.
We plan to keep emitting such warnings by default.
Introduce a flag that allows disabling warnings on local variables that are
not of a known move-unsafe type. If it doesn't work out as we expected,
we'll just flip the flag.
We still warn on move-unsafe objects and unsafe operations on known move-safe
objects.
Differential Revision: https://reviews.llvm.org/D55730
llvm-svn: 349327
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This re-applies commit r349226 that was reverted in r349233 due to failures
on clang-x64-windows-msvc.
Specify enum type as unsigned for use in bit field. Otherwise overflows
may cause UB.
Differential Revision: https://reviews.llvm.org/D55388
llvm-svn: 349326
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
StaticAnalyzer uses the CFG-based RelaxedLiveVariables analysis in order to,
in particular, figure out values of which expressions are still needed.
When the expression becomes "dead", it is garbage-collected during
the dead binding scan.
Expressions that constitute branches/bodies of control flow statements,
eg. `E1' in `if (C1) E1;' but not `E2' in `if (C2) { E2; }', were kept alive
for too long. This caused false positives in MoveChecker because it relies
on cleaning up loop-local variables when they go out of scope, but some of those
live-for-too-long expressions were keeping a reference to those variables.
Fix liveness analysis to correctly mark these expressions as dead.
Add a debug checker, debug.DumpLiveStmts, in order to test expressions liveness.
Differential Revision: https://reviews.llvm.org/D55566
llvm-svn: 349320
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D54834
llvm-svn: 349283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch merely reorganizes some things, and features no functional change.
In detail:
* Provided documentation, or moved existing documentation in more obvious
places.
* Added dividers. (the //===----------===// thing).
* Moved getAllocationFamily, printAllocDeallocName, printExpectedAllocName and
printExpectedDeallocName in the global namespace on top of the file where
AllocationFamily is declared, as they are very strongly related.
* Moved isReleased and MallocUpdateRefState near RefState's definition for the
same reason.
* Realloc modeling was very poor in terms of variable and structure naming, as
well as documentation, so I renamed some of them and added much needed docs.
* Moved function IdentifierInfos to a separate struct, and moved isMemFunction,
isCMemFunction adn isStandardNewDelete inside it. This makes the patch affect
quite a lot of lines, should I extract it to a separate one?
* Moved MallocBugVisitor out of MallocChecker.
* Preferred switches to long else-if branches in some places.
* Neatly organized some RUN: lines.
Differential Revision: https://reviews.llvm.org/D54823
llvm-svn: 349281
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept.
It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend,
whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can
imagine, used to circumvent the problem that the registry functions of the
checkers are located in the clangStaticAnalyzerCheckers library, but that
library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend
depends on both of those libraries.
One can make the observation however, that CheckerRegistry has no place in Core,
it isn't used there at all! The only place where it is used is Frontend, which
is where it ultimately belongs.
This move implies that since
include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function:
class CheckerRegistry;
void registerBuiltinCheckers(CheckerRegistry ®istry);
it had to re purposed, as CheckerRegistry is no longer available to
clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h,
which actually describes it a lot better -- it does not contain the registration
functions for checkers, but only those generated by the tblgen files.
Differential Revision: https://reviews.llvm.org/D54436
llvm-svn: 349275
|
| |
|
|
|
|
|
|
| |
The removed codepath was dead.
Differential Revision: https://reviews.llvm.org/D55697
llvm-svn: 349266
|
| |
|
|
|
|
|
|
| |
This reverts commit r349226.
Fails on an MSVC buildbot.
llvm-svn: 349233
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The checker wasn't prepared to see the dealloc message sent to the class itself
rather than to an instance, as if it was +dealloc.
Additionally, it wasn't prepared for pure-unknown or undefined self values.
The new guard covers that as well, but it is annoying to test because
both kinds of values shouldn't really appear and we generally want to
get rid of all of them (by modeling unknown values with symbols and
by warning on use of undefined values before they are used).
The CHECK: directive for FileCheck at the end of the test looks useless,
so i removed it.
Differential Revision: https://reviews.llvm.org/D55680
llvm-svn: 349228
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use trackExpressionValue() (previously known as trackNullOrUndefValue())
to track index value in the report, so that the user knew
what Static Analyzer thinks the index is.
Additionally, implement printState() to help debugging the checker later.
Differential Revision: https://reviews.llvm.org/D55458
llvm-svn: 349227
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calling operator*() or operator->() on a null STL smart pointer is
undefined behavior.
Smart pointers are specified to become null after being moved from.
So we can't warn on arbitrary method calls, but these two operators
definitely make no sense.
The new bug is fatal because it's an immediate UB,
unlike other use-after-move bugs.
The work on a more generic null smart pointer dereference checker
is still pending.
Differential Revision: https://reviews.llvm.org/D55388
llvm-svn: 349226
|
| |
|
|
|
|
|
|
| |
No functional change intended.
Differential Revision: https://reviews.llvm.org/D55387
llvm-svn: 349225
|
| |
|
|
|
|
|
|
|
|
|
| |
Some C++ standard library classes provide additional guarantees about their
state after move. Suppress warnings on such classes until a more precise
behavior is implemented. Warnings for locals are not suppressed anyway
because it's still most likely a bug.
Differential Revision: https://reviews.llvm.org/D55307
llvm-svn: 349191
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a moved-from object is passed into a conservatively evaluated function
by pointer or by reference, we assume that the function may reset its state.
Make sure it doesn't apply to const pointers and const references. Add a test
that demonstrates that it does apply to rvalue references.
Additionally, make sure that the object is invalidated when its contents change
for reasons other than invalidation caused by evaluating a call conservatively.
In particular, when the object's fields are manipulated directly, we should
assume that some sort of reset may be happening.
Differential Revision: https://reviews.llvm.org/D55289
llvm-svn: 349190
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- explicit_bzero has limited scope/usage only for security/crypto purposes but is non-optimisable version of memset/0 and bzero.
- explicit_memset has similar signature and semantics as memset but is also a non-optimisable version.
Reviewers: NoQ
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D54592
llvm-svn: 348884
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Memoization dose not seem to be necessary, as other statement visitors
run just fine without it,
and in fact seems to be causing memory corruptions.
Just removing it instead of investigating the root cause.
rdar://45945002
Differential Revision: https://reviews.llvm.org/D54921
llvm-svn: 348822
|
| |
|
|
|
|
| |
To be removed once the clients update.
llvm-svn: 348821
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
os_consumed summary
This is currently a diagnostics, but might be upgraded to an error in the future,
especially if we introduce os_return_on_success attributes.
rdar://46359592
Differential Revision: https://reviews.llvm.org/D55530
llvm-svn: 348820
|
| |
|
|
|
|
|
|
| |
printed properly
Differential Revision: https://reviews.llvm.org/D55528
llvm-svn: 348819
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned`
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D55475
llvm-svn: 348755
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
primitive types
Escaping to void * / uint64_t / others non-OSObject * should stop tracking,
as such functions can have heterogeneous semantics depending on context,
and can not always be annotated.
rdar://46439133
Differential Revision: https://reviews.llvm.org/D55465
llvm-svn: 348675
|
| |
|
|
|
|
|
|
|
| |
Allow enabling and disabling tracking of ObjC/CF objects
separately from tracking of OS objects.
Differential Revision: https://reviews.llvm.org/D55400
llvm-svn: 348638
|
| |
|
|
|
|
|
|
|
|
|
|
| |
IncludeAllocationLine
The option has no tests, is not used anywhere, and is actually
incorrect: it prints the line number without the reference to a file,
which can be outright incorrect.
Differential Revision: https://reviews.llvm.org/D55385
llvm-svn: 348637
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
increments past the end() of containers
Previously, the iterator range checker only warned upon dereferencing of
iterators outside their valid range as well as increments and decrements of
out-of-range iterators where the result remains out-of-range. However, the C++
standard is more strict than this: decrementing begin() or incrementing end()
results in undefined behaviour even if the iterator is not dereferenced
afterwards. Coming back to the range once out-of-range is also undefined.
This patch corrects the behaviour of the iterator range checker: warnings are
given for any operation whose result is ahead of begin() or past the end()
(which is the past-end iterator itself, thus now we are speaking of past
past-the-end).
Differential Revision: https://reviews.llvm.org/D53812
llvm-svn: 348245
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iterators stored in a region
If an iterator is represented by a derived C++ class but its comparison operator
is for its base the iterator checkers cannot recognize the iterators compared.
This results in false positives in very straightforward cases (range error when
dereferencing an iterator after disclosing that it is equal to the past-the-end
iterator).
To overcome this problem we always use the region of the topmost base class for
iterators stored in a region. A new method called getMostDerivedObjectRegion()
was added to the MemRegion class to get this region.
Differential Revision: https://reviews.llvm.org/D54466
llvm-svn: 348244
|
| |
|
|
|
|
|
|
|
| |
Includes "resize" and "shrink" because they can reset the object to a known
state in certain circumstances.
Differential Revision: https://reviews.llvm.org/D54563
llvm-svn: 348235
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The warning piece traditionally describes the bug itself, i.e.
"The bug is a _____", eg. "Attempt to delete released memory",
"Resource leak", "Method call on a moved-from object".
Event pieces produced by the visitor are usually in a present tense, i.e.
"At this moment _____": "Memory is released", "File is closed",
"Object is moved".
Additionally, type information is added into the event pieces for STL objects
(in order to highlight that it is in fact an STL object), and the respective
event piece now mentions that the object is left in an unspecified state
after it was moved, which is a vital piece of information to understand the bug.
Differential Revision: https://reviews.llvm.org/D54560
llvm-svn: 348229
|