[cfe-dev] Adding a CFG node for the allocation call in a new-expression

[Jordan Rose]

On Apr 5, 2012, at 14:28, Anna Zaks wrote:

> 
> On Apr 4, 2012, at 10:06 AM, Jordan Rose wrote:
> 
>> - What does it mean to be PreStmt<CXXNewExpr> if the allocation and the initializer have already happened? (Note that right neither PreStmt nor PostStmt checks are done on CXXNewExpr, but that's easily fixed.)
>> 
> 
> What are the issues with calling PreStmt<CXXNewExpr> before evaluation of any statements related to new (except that it's more difficult to implement)? That's what checker writers would expect from the callback.

Now that the CFG is linearized, it's hard to know what that means. For a normal call, the arguments are evaluated before the PreStmt<CallExpr> callback, then the call itself is inlined or modelled, then there's the PostStmt<CallExpr> callback. For a CXXNewExpr, though, the CFG looks like this:

1. Evaluate all placement args.
2. CFGAllocation ***
3. Evaluate all constructor args.
4. Evaluate the constructor.
5. Evaluate the CXXNewExpr.

It's impractical to put the PreStmt<CXXNewExpr> call before all of that, because that removes the whole effort of a linearized CFG. The constructor args really might not be evaluated until after the allocation, according to the standard, but moving them is impractical since there /is/ a CXXConstructExpr (or similar) inside the CXXNewExpr, and the CFG treats that like any other expression. IIRC, we don't have any other Pre/Post pairs that stretch across multiple CFG nodes.


>> - How can we represent "calls" that don't have associated expressions? I'm starting to think CallOrObjCMessage needs to turn into a real "abstract call" model which may or may not have expressions for the arguments and can handle regular calls, messages, constructors, destructors, allocations, and deletions.  New checks: preCall and postCall. But that's a bit outside the scope of this patch.
>> 
> 
> Is this needed to allow callbacks on the allocation? Do we have to generalize here or could we just provide a separate callback for it (if someone needs it)?

It's certainly possible to add a separate callback; what I'm thinking of, though, is inlining and generic checks. Right now RetainCountChecker implements several callbacks and awkwardly filters them into a single evalSummary. AttrNonNullChecker checks the "nonnull" attribute, which ought to apply to the allocation call as much as anything else. I feel like the majority of call checkers that /don't/ deal with specific functions (i.e. unlike CStringChecker and such) probably need to reason about /every/ sort of call.

This is a long-term idea, though; I'm not angling to put it in right now.

Jordy