ObjCObjectType, which is basically just a pair of
one of {primitive-id, primitive-Class, user-defined @class}
with
a list of protocols.
An ObjCObjectPointerType is therefore just a pointer which always points to
one of these types (possibly sugared). ObjCInterfaceType is now just a kind
of ObjCObjectType which happens to not carry any protocols.
Alter a rather large number of use sites to use ObjCObjectType instead of
ObjCInterfaceType. Store an ObjCInterfaceType as a pointer on the decl rather
than hashing them in a FoldingSet. Remove some number of methods that are no
longer used, at least after this patch.
By simplifying ObjCObjectPointerType, we are now able to easily remove and apply
pointers to Objective-C types, which is crucial for a certain kind of ObjC++
metaprogramming common in WebKit.
llvm-svn: 103870
Amadini.
This change introduces a new expression node type, OffsetOfExpr, that
describes __builtin_offsetof. Previously, __builtin_offsetof was
implemented using a unary operator whose subexpression involved
various synthesized array-subscript and member-reference expressions,
which was ugly and made it very hard to instantiate as a
template. OffsetOfExpr represents the AST more faithfully, with proper
type source information and a more compact representation.
OffsetOfExpr also has support for dependent __builtin_offsetof
expressions; it can be value-dependent, but will never be
type-dependent (like sizeof or alignof). This commit introduces
template instantiation for __builtin_offsetof as well.
There are two major caveats to this patch:
1) CodeGen cannot handle the case where __builtin_offsetof is not a
constant expression, so it produces an error. So, to avoid
regressing in C, we retain the old UnaryOperator-based
__builtin_offsetof implementation in C while using the shiny new
OffsetOfExpr implementation in C++. The old implementation can go
away once we have proper CodeGen support for this case, which we
expect won't cause much trouble in C++.
2) __builtin_offsetof doesn't work well with non-POD class types,
particularly when the designated field is found within a base
class. I will address this in a subsequent patch.
Fixes PR5880 and a bunch of assertions when building Boost.Python
tests.
llvm-svn: 102542
thing. Audit all uses of Type::isStructure(), changing those calls to
isStructureOrClassType() as needed (which is alsmost
everywhere). Fixes the remaining failure in Boost.Utility/Swap.
llvm-svn: 102386
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.
llvm-svn: 101972
case in GRExprEngine::Visit (in r101129). Instead, enumerate all Stmt cases and have
no 'default' case in the switch statement. When we encounter a Stmt we don't handle,
we should explicitly add it to the switch statement.
llvm-svn: 101378
them the same way as fields. This fixes a regression in RegionStore::RemoveDeadbindings()
that emerged from going to the cluster-based analysis.
llvm-svn: 100570
This introduces FunctionType::ExtInfo to hold the calling convention and the
noreturn attribute. The next patch will extend it to include the regparm
attribute and fix the bug.
llvm-svn: 99920
a scalar variable with a scalar parameter. This is a
form of defensive programming. If the variable is unused,
it will be caused by -Wunused-variable.
llvm-svn: 98795
Beyond simplifying the algorithm significantly, we no longer
need to build subregion maps in RemoveDeadBindings(). This
and other changes cause a significant speedup: the time to
analyze sqlite3.c (single core) drops by 14%.
llvm-svn: 98159
cluster analysis algorithm as RegionStore::InvalidateRegions().
Beyond simplifying the algorithm significantly, we no longer
need to build subregion maps in RemoveDeadBindings(). This
and other changes cause a significant speedup: the time to
analyze sqlite3.c (single core) drops by 14%.
llvm-svn: 98144
we now may have identical states with different analysis context.
Set the right AnalysisContext in state when entering and leaving a callee.
With both of the above changes, we can pass the test case.
llvm-svn: 97724
After discussion with Zhongxing, don't force the initializer of DeclStmts to be
block-level expressions.
This led to some interesting fallout:
[UninitializedValues]
Always visit the initializer of DeclStmts (do not assume they are block-level expressions).
[BasicStore]
With initializers of DeclStmts no longer block-level expressions, this causes self-referencing initializers (e.g. 'int x = x') to no longer cause the initialized variable to be live before the DeclStmt. While this is correct, it caused BasicStore::RemoveDeadBindings() to prune off the values of these variables from the initial store (where they are set to uninitialized). The fix is to back-port some (and only some) of the lazy-binding logic from RegionStore to
BasicStore. Now the default values of local variables are determined lazily as opposed
to explicitly initialized.
llvm-svn: 97591
Use this information to find the returned value and bind it to CallExpr in
ProcessCallExit.
And there is no need to remove dead bindings in ProcessCallExit, because
a. it would clean up the return value bound to CallExpr
b. we still would do it in the next ProcessStmt(), where we would not misclean
up the return value.
llvm-svn: 97225
This patch implements the CallEnter/CallExit idea of Ted.
Add two interfaces to GRSubEngine: ProcessCallEnter, ProcessCallExit.
The CallEnter program point uses caller's location context. The
CallExit program point uses callee's location context.
CallEnter is built by GRStmtNodeBuilder. CallExit is built by
GREndPathNodeBuilder.
llvm-svn: 97122
to various MacOS X functions. The checks in BasicObjCFoundationChecks.cpp will
gradually be migrated here.
As a first check, check that when 'dispatch_once()' is passed a predicate value
that has non-local storage.
llvm-svn: 97116
to various unix/posix functions, e.g. 'open()'.
As a first check, check that when 'open()' is passed 'O_CREAT' that it has
a third argument.
llvm-svn: 97086
pointer (for defensive programming). This matches the behavior with
assigning NULL to a regular pointer. Fixes <rdar://problem/7631278>.
llvm-svn: 96985
of operating on each code decl. This exposes two flaws in AnalysisConsumer
that should eventually be fixed:
(1) It is not possible to associate multiple "actions" with a single
command line argument. This will require the notion of an
"analysis" group, and possibly tablegen support. (although eventually
we want to support dynamically loading analyses as well)
(2) AnalysisConsumer may not actually be scanning the declarations in namespaces.
We'll experiment first in LLVMConventionsChecker before changing the
behavior in AnalysisConsumer.
llvm-svn: 96183
Currently these checks are intended to be largely syntactical, but may get more
sophisticated over time.
As an initial foray into this brave new world, emit a static analyzer warning
when binding a temporary 'std::string' to an 'llvm::StringRef' where the
lifetime of the 'std::string' does not outlive the 'llvm::StringRef'.
llvm-svn: 96147
NULL, not the store, to determine if a lookup succeeded. The store
can be null if it contained no bindings. This fixes a false positive
reported to me by a user of the analyzer.
llvm-svn: 95679
a different return type. While we don't emit any errors (yet), at
least we avoid cases where we might crash because of an assertion
failure later on (when the return type differs from what is expected).
llvm-svn: 95268
RegionStoreManager::InvalidateRegions() by adjusting the worklist to
iterate over BindingKeys instead of MemRegions. We also only need to
do the actual invalidation work on base regions, and for non-base
regions just blow away their bindings.
llvm-svn: 95200
not build a subregion map and instead do a single scan of the store.
This is done by building "region clusters" that represent the
collection of regions that have the same base region. Invalidating
any region in a cluster means that they all should get invalidated.
This change brought out a point that Zhongxing mentioned to me
offline: the flattened memory binding has issues distinguishing
between direct and default bindings. For example, setting the default
value for an entire struct is the same as binding to the first
element. To address this problem, I moved the binding "tag" (Direct
or Default) from BindingVal to BdingKey (and removed BindingVal
entirely). This requires us to do double lookups in some cases; and
there is still much more cleanup that can be done.
This change produced a noticeable speedup when analyzing sqlite3 (a
reduction of 4% in running time).
llvm-svn: 95193
reusable and modular API pieces.
Start by pulling the logic for deriving the Cocoa naming convention
into a separate API, header, and source file.
llvm-svn: 94662
(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.
llvm-svn: 94406
Zhongxing Xu