| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
While this work is still fairly tentative (destructors are still left out of
the CFG by default), we now handle destructors in the same way as any other
calls, instead of just automatically trying to inline them.
llvm-svn: 160020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are currently unused, but are intended to be used in lieu of PreStmt
and PostStmt when the call is implicit (e.g. an automatic object destructor).
This also modifies the Data1 field of ProgramPoints to allow storing any
pointer-sized value, as opposed to only aligned pointers. This is necessary
to store SourceLocations.
There is currently no BugReporter support for these; they should be skipped
over in any diagnostic output.
This commit also tags checkers that currently rely on function calls only
occurring at StmtPoints.
llvm-svn: 160019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our current inlining support (specifically RegionStore::enterStackFrame)
doesn't know that calls to overloaded operators may be calls to non-static
member functions, and that in these cases the first argument should be
treated as 'this'. This caused incorrect results and sometimes crashes.
The long-term fix will be to rewrite RegionStore::enterStackFrame to use
CallEvent and its subclasses, but for now we can just disable these
problematic calls by classifying them under a new CallEvent,
CXXMemberOperatorCall.
llvm-svn: 159692
|
|
|
|
|
|
|
| |
This is NOT full-blown support for operator new, but removes some nasty
duplicated code introduced in r158784.
llvm-svn: 159608
|
|
|
|
| |
llvm-svn: 159563
|
|
|
|
|
|
|
|
| |
The preObjCMessage and postObjCMessage callbacks now take an ObjCMethodCall
argument, which can represent an explicit message send (ObjCMessageSend) or an
implicit message generated by a property access (ObjCPropertyAccess).
llvm-svn: 159559
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the CallEvent subclass ObjCMessageInvocation was just a wrapper
around the existing ObjCMessage abstraction (over message sends and property
accesses). Now, we have abstract CallEvent ObjCMethodCall with subclasses
ObjCMessageSend and ObjCPropertyAccess.
In addition to removing yet another wrapper object, this should make it easy
to add a ObjCSubscriptAccess call event soon.
llvm-svn: 159558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ended allowing quite a bit of cleanup, and some minor changes.
- CallEvent makes it easy to use hasNonZeroCallbackArg more aggressively, which
we check in order to avoid false positives with callbacks that might release
the object.
- In order to support this for functions which consume their arguments, there
are two new ArgEffects: DecRefAndStopTracking and DecRefMsgAndStopTracking.
These act just like StopTracking, except that if the object only had a
return count of +1 it's now considered released instead (so we still get
use-after-free messages).
- On the plus side, we no longer have to special-case
+[NSObject performSelector:withObject:afterDelay:] and friends.
- The use of IdentifierInfos in the method summary cache is now hidden; only
the ObjCInterfaceDecl gets passed around most of the time.
- Since we cache all "simple" summaries and check every function call, there is
no real benefit to having NULL stand in for default summaries anymore.
- Whitespace, unused methods, etc.
Even more simplification to come when we get check::postCall and can unify all
these other post* checks.
llvm-svn: 159555
|
|
|
|
|
|
|
|
|
|
| |
This is intended to replace CallOrObjCMessage, and is eventually intended to be
used for anything that cares more about /what/ is being called than /how/ it's
being called. For example, inlining destructors should be the same as inlining
blocks, and checking __attribute__((nonnull)) should apply to the allocator
calls generated by operator new.
llvm-svn: 159554
|
|
|
|
| |
llvm-svn: 159245
|
|
|
|
|
|
|
|
|
| |
We already didn't track objects that have delegates or callbacks or
objects that are passed through void * "context pointers". It's a
not-uncommon pattern to release the object in its callback, and so
the leak message we give is not very helpful.
llvm-svn: 158532
|
|
|
|
|
|
| |
-Wunused-private-field.
llvm-svn: 158086
|
|
|
|
| |
llvm-svn: 157531
|
|
|
|
| |
llvm-svn: 156699
|
|
|
|
|
|
| |
references (thus extending their lifetime).
llvm-svn: 156346
|
|
|
|
|
|
|
| |
As per Jordy's and Ted's comment, use the default StopTracking summary
instead of adding all arguments to ScratchArs.
llvm-svn: 156310
|
|
|
|
|
|
| |
Fixes radar://10973977.
llvm-svn: 156215
|
|
|
|
|
|
| |
warning.
llvm-svn: 155966
|
|
|
|
|
|
| |
retained objects. I know there is an SDK enhancement request for this to have the cf_returns_retained annotation, so this is just a stop gap.
llvm-svn: 155887
|
|
|
|
|
|
| |
pthread_setspecific and it should just give up when it sees it. Fixes <rdar://problem/11282706>.
llvm-svn: 155613
|
|
|
|
|
|
|
|
|
|
| |
change,
consolidate some commonly used category strings into global references (more of this can be done, I just did a few).
Fixes <rdar://problem/11191537>.
llvm-svn: 154121
|
|
|
|
|
|
|
|
| |
Fixes a false positive (radar://11152419). The current solution of
adding the info into 3 places is quite ugly. Pending a generic pointer
escapes callback.
llvm-svn: 153731
|
|
|
|
|
|
|
|
|
|
|
|
| |
assigned to a struct. This is fallout from inlining results, which expose
far more patterns where people stuff CF objects into structs and pass them
around (and we can reason about it). The problem is that we don't have
a general way to detect when values have escaped, so as an intermediate step
we need to eagerly prune out such tracking.
Fixes <rdar://problem/11104566>.
llvm-svn: 153489
|
|
|
|
|
|
| |
to reset diagnostic generation.
llvm-svn: 153368
|
|
|
|
|
|
| |
function call was inlined (i.e., we do not need to apply summaries in such cases).
llvm-svn: 153309
|
|
|
|
|
|
| |
free its argument later. Fixes <rdar://problem/11059275>.
llvm-svn: 153244
|
|
|
|
|
|
| |
So that others could use it as well. No functionality change.
llvm-svn: 153211
|
|
|
|
|
|
|
|
|
|
| |
than explicitly keeping DoNothing and StopTracking summaries and nothing else.
I tried to test the effects of this change on memory usage and run time, but what I saw on retain-release.m was indistinguishable from noise (debug and release builds). Even so, some caveman profiling showed 101 cache hits that we would have generated new summaries for before (i.e. not default or stop summaries), and the more code we analyze, the more memory we should save.
Maybe we should have a standard project for benchmarking the retain count checker's memory and time?
llvm-svn: 153007
|
|
|
|
|
|
| |
methods. No functionality change.
llvm-svn: 153001
|
|
|
|
|
|
|
|
|
|
| |
functionality change.
The cocoa::deriveNamingConventions helper is just using method families anyway now, and the way RetainSummaryTemplate works means we're allocating an extra summary for every method with a relevant family.
Also, fix RetainSummaryTemplate to do the right thing w/r/t annotating an /existing/ summary. This was probably the real cause of <rdar://problem/10824732> and the fix in r152448.
llvm-svn: 152998
|
|
|
|
|
|
|
|
| |
counting autoreleases. Fixes PR10376.
(Also, 80-column violations.)
llvm-svn: 152976
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
| |
annotations. Fixes <rdar://problem/10824732>.
llvm-svn: 152448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
symbols and regions.
Essentially, a bug centers around a story for various symbols and regions. We should only include
the path diagnostic events that relate to those symbols and regions.
The pruning is done by associating a set of interesting symbols and regions with a BugReporter, which
can be modified at BugReport creation or by BugReporterVisitors.
This patch reduces the diagnostics emitted in several of our test cases. I've vetted these as
having desired behavior. The only regression is a missing null check diagnostic for the return
value of realloc() in test/Analysis/malloc-plist.c. This will require some investigation to fix,
and I have added a FIXME to the test case.
llvm-svn: 152361
|
|
|
|
| |
llvm-svn: 152139
|
|
|
|
|
|
| |
closest function context (RetainCountChecker).
llvm-svn: 151661
|
|
|
|
|
|
| |
message.
llvm-svn: 151657
|
|
|
|
|
|
| |
ReturnStmt unless we are in the top-level call frame. We can do more later, but this makes the checker self-consistent (and fixes a crash).
llvm-svn: 151426
|
|
|
|
|
|
| |
<rdar://problem/10640253>.
llvm-svn: 150892
|
|
|
|
|
|
| |
for functions called more than once.
llvm-svn: 150849
|
|
|
|
|
|
|
|
|
|
|
|
| |
(In response of Ted's review of r150112.)
This moves the logic which checked if a symbol escapes through a
parameter to invalidateRegionCallback (instead of post CallExpr visit.)
To accommodate the change, added a CallOrObjCMessage parameter to
checkRegionChanges callback.
llvm-svn: 150513
|
|
|
|
| |
llvm-svn: 149982
|
|
|
|
| |
llvm-svn: 149939
|
|
|
|
|
|
|
| |
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
llvm-svn: 149799
|
|
|
|
| |
llvm-svn: 149798
|
|
|
|
|
|
|
|
| |
include.
Fix all the transitive include users.
llvm-svn: 149783
|
|
|
|
|
|
|
|
| |
At this point this is largely cosmetic, but it opens the door to replace
ProgramStateRef with a smart pointer that more eagerly acts in the role
of reclaiming unused ProgramState objects.
llvm-svn: 149081
|
|
|
|
|
|
| |
appropriate or when GCC requires it)
llvm-svn: 148292
|
|
|
|
|
|
| |
This allows -Wswitch-enum to find switches that need updating when these enums are modified.
llvm-svn: 148281
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
entries map from
(Stmt*,LocationContext*) pairs to SVals instead of Stmt* to SVals.
This is needed to support basic IPA via inlining. Without this, we cannot tell
if a Stmt* binding is part of the current analysis scope (StackFrameContext) or
part of a parent context.
This change introduces an uglification of the use of getSVal(), and thus takes
two steps forward and one step back. There are also potential performance implications
of enlarging the Environment. Both can be addressed going forward by refactoring the
APIs and optimizing the internal representation of Environment. This patch
mainly introduces the functionality upon when we want to build upon (and clean up).
llvm-svn: 147688
|