On Jul 27, 2012, at 11:55 , John McCall <[email protected]> wrote:
> 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.
We should probably start modelling (1) and (2) (and someday (3)), but what I
meant is that since the CFG does not include any implicit message sends, the
analyzer won't see them either. Thanks for the summary of when that occurs,
though.
Jordan
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
