On Jul 26, 2012, at 9:37 AM, Jordan Rose wrote:
> On Jul 26, 2012, at 9:29 , jahanian <[email protected]> wrote:
>>> - for (Decl::redecl_iterator I = MD->redecls_begin(), E =
>>> MD->redecls_end();
>>> - I != E; ++I) {
>>> - if (cast<ObjCMethodDecl>(*I)->isThisDeclarationADefinition())
>>> - return *I;
>>> + const ObjCMessageExpr *E = getOriginExpr();
>>
>> getOriginExpr may return null. You should check for that.
>
> Right now it's safe to assume all ObjCMethodCalls have origin expressions,
> because all our implicit message sends are already abstracted using
> PseudoObjectExpr. I guess that may change in the future.
The only implicit message sends that aren't directly represented in the AST
these days are:
(1) the implicit [super dealloc] in an ARC dealloc method, because it has
destructor-like semantics, i.e. it needs to be run even on early exits from the
function;
(2) the message sends implementing literals, because we don't actually
guarantee that they'll always be message sends — if we decide it's worthwhile
to implement them as runtime calls, we will;
(3) the message sends implementing the ObjC "fast enumeration" loop.
I don't know if the static analyzer models the message sends for fast
enumeration.
It's unlikely that we will ever add new user visible message sends ("user
visible" in the sense that the sends for literals aren't) to arbitrarily-typed
methods; that's exactly the sort of thing that we wanted to get away from when
we introduced PseudoObjectExpr. It's possible that we might add new things
like the fast enumeration loop, where the selectors are checked against
specific signatures.
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
