| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122420 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120873 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a node in the trimmed graph might not always
correctly map back to the original error node.
This could cause a crash in some cases when
flagging memory leaks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120795 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120696 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ImmutableSet/ImmtuableMap/ImmutableList APIs.
Along the way, clean up some method names in
the static analyzer so that they are more
descriptive and/or start with lowercase letters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120071 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the assumption that EndNode == ErrorNode, but upcoming changes will break this.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114065 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
trimmed graph (in BugReporter). This fixes a problem where a leak that happened to occur on both an exit() path and a non-exit() path was getting reported with the exit() path (which users don't care about).
This fixes:
<rdar://problem/8331641> leak reports should not show paths that end with exit() (but ones that don't end with exit())
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113524 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
struct. Clang would zero out the enum and pointer in the struct in some conditions, but GCC would never zero out the values.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112909 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112857 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- SourceRange highlighting is only given for the relevant side of the operator (assignments give both)
- Added PostVisitBinaryOperator hook to retrieve the ExplodedNode for an operator
- Added a BugReporterVisitor to display the last store to every VarDecl in a Stmt
- Changed bug reporting to use the new BugReporterVisitor
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112839 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
bugs of the same
type at the same location.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106209 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expressions, to improve source-location information, clarify the
actual receiver of the message, and pave the way for proper C++
support. The ObjCMessageExpr node represents four different kinds of
message sends in a single AST node:
1) Send to a object instance described by an expression (e.g., [x method:5])
2) Send to a class described by the class name (e.g., [NSString method:5])
3) Send to a superclass class (e.g, [super method:5] in class method)
4) Send to a superclass instance (e.g., [super method:5] in instance method)
Previously these four cases where tangled together. Now, they have
more distinct representations. Specific changes:
1) Unchanged; the object instance is represented by an Expr*.
2) Previously stored the ObjCInterfaceDecl* referring to the class
receiving the message. Now stores a TypeSourceInfo* so that we know
how the class was spelled. This both maintains typedef information
and opens the door for more complicated C++ types (e.g., dependent
types). There was an alternative, unused representation of these
sends by naming the class via an IdentifierInfo *. In practice, we
either had an ObjCInterfaceDecl *, from which we would get the
IdentifierInfo *, or we fell into the case below...
3) Previously represented by a class message whose IdentifierInfo *
referred to "super". Sema and CodeGen would use isStr("super") to
determine if they had a send to super. Now represented as a
"class super" send, where we have both the location of the "super"
keyword and the ObjCInterfaceDecl* of the superclass we're
targetting (statically).
4) Previously represented by an instance message whose receiver is a
an ObjCSuperExpr, which Sema and CodeGen would check for via
isa<ObjCSuperExpr>(). Now represented as an "instance super" send,
where we have both the location of the "super" keyword and the
ObjCInterfaceDecl* of the superclass we're targetting
(statically). Note that ObjCSuperExpr only has one remaining use in
the AST, which is for "super.prop" references.
The new representation of ObjCMessageExpr is 2 pointers smaller than
the old one, since it combines more storage. It also eliminates a leak
when we loaded message-send expressions from a precompiled header. The
representation also feels much cleaner to me; comments welcome!
This patch attempts to maintain the same semantics we previously had
with Objective-C message sends. In several places, there are massive
changes that boil down to simply replacing a nested-if structure such
as:
if (message has a receiver expression) {
// instance message
if (isa<ObjCSuperExpr>(...)) {
// send to super
} else {
// send to an object
}
} else {
// class message
if (name->isStr("super")) {
// class send to super
} else {
// send to class
}
}
with a switch
switch (E->getReceiverKind()) {
case ObjCMessageExpr::SuperInstance: ...
case ObjCMessageExpr::Instance: ...
case ObjCMessageExpr::SuperClass: ...
case ObjCMessageExpr::Class:...
}
There are quite a few places (particularly in the checkers) where
send-to-super is effectively ignored. I've placed FIXMEs in most of
them, and attempted to address send-to-super in a reasonable way. This
could use some review.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101972 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99731 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99064 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This avoids redundant diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99063 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We were inserting a value into a std::vector<> while iterating over
it, which could cause the underlying memory to get deallocated
and reallocated. While not the best solution, use an llvm::ImmutableList
for now as it is safely supports insertions during iteration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99058 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expression", statistical evidence indicates it has some kind of memory error.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
is not evaluated because the receiver is nil.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99024 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96341 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'include/Checker/BugReporter'
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94428 91177308-0d34-0410-b5e6-96231b3b80d8
|
