[cfe-commits] r160768 - in /cfe/trunk: include/clang/StaticAnalyzer/Core/PathSensitive/Calls.h include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h lib/StaticAnalyzer/Core/Calls.cpp lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp lib/StaticAnalyzer/Core/ExprEngineObjC.cpp test/Analysis/inlining/ test/Analysis/inlining/InlineObjCClassMethod.m

[John McCall]

On Jul 26, 2012, at 9:37 AM, Jordan Rose wrote:
> On Jul 26, 2012, at 9:29 , jahanian <fjahanian at apple.com> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120727/fb24dcc6/attachment.html>