Age | Commit message (Collapse) | Author |
|
libclangGRCore
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122421 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122420 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
implicit lvalue-to-rvalue casts that John McCall
recently introduced. This causes a whole bunch
of logic in the analyzer for handling lvalues
to vanish. It does, however, raise a few issues
in the analyzer w.r.t to modeling various constructs
(e.g., field accesses to compound literals).
The .c/.m analysis test cases that fail are
due to a missing lvalue-to-rvalue cast that
will get introduced into the AST. The .cpp
failures were more than I could investigate in
one go, and the patch was already getting huge.
I have XFAILED some of these tests, and they
should obviously be further investigated.
Some highlights of this patch include:
- CFG no longer requires an lvalue bit for
CFGElements
- StackFrameContext doesn't need an 'asLValue'
flag
- The "VisitLValue" path from GRExprEngine has
been eliminated.
Besides the test case failures (XFAILed), there
are surely other bugs that are fallout from
this change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121960 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to 'assumeXXX'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120614 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
|
|
to the new constants.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112047 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110784 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108811 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
|
|
users of getNameAsString on a stream.
The next step is to print the name directly into the stream, avoiding a temporary std::string copy.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@101632 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
|
|
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
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95545 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
GRState::getSVal(MemRegion*) => Load().
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95541 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
|
|
(1) libAnalysis is a generic analysis library that can be used by
Sema. It defines the CFG, basic dataflow analysis primitives, and
inexpensive flow-sensitive analyses (e.g. LiveVariables).
(2) libChecker contains the guts of the static analyzer, incuding the
path-sensitive analysis engine and domain-specific checks.
Now any clients that want to use the frontend to build their own tools
don't need to link in the entire static analyzer.
This change exposes various obvious cleanups that can be made to the
layout of files and headers in libChecker. More changes pending. :)
This change also exposed a layering violation between AnalysisContext
and MemRegion. BlockInvocationContext shouldn't explicitly know about
BlockDataRegions. For now I've removed the BlockDataRegion* from
BlockInvocationContext (removing context-sensitivity; although this
wasn't used yet). We need to have a better way to extend
BlockInvocationContext (and any LocationContext) to add
context-sensitivty.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94406 91177308-0d34-0410-b5e6-96231b3b80d8
|