[cfe-commits] r158784 - in /cfe/trunk: lib/StaticAnalyzer/Core/ExprEngineCXX.cpp test/Analysis/new-fail.cpp test/Analysis/new.cpp

[Jordan Rose]

On Jun 19, 2012, at 10:07 PM, Anna Zaks wrote:

> Can we extend CallOrObjCMessage with the CXXNewExpr? I know you think CallOrObjCMessage should be rewritten, but it's a much better solution than copying a bunch of dense code including 4 original FIXMEs and still not having the complete invalidation as the result. Also, what do we win from adding the invalidation? All the false positives seemed to have moved into a test which is XFAILED. If we don't win anything and it's too hard to reuse CallOrObjCMessage, we could just not do any invalidation (you already have a fixit notes for it).

The reason CallOrObjCMessage is hard to adapt for CXXNewExpr is because the first placement arg is the size being allocated, which doesn't have a corresponding expression. CallOrObjCMessage users tend to assume that they can always look at the type and/or source range of an argument value.

I think I actually did hack this up in some of my CXXNewExpr work months ago---I'll look around on my personal hard drive and see what I've got---but I think I just sidestepped the problem by using the placement args as written as the list of arguments. This is a problem because then the arg exprs don't match up with the FunctionDecl being used.

The case that this handles is that otherwise this code says 'x' and 'y' are uninitialized:

int x;
new (&x) int;

int *y = (int*)malloc(sizeof(int));
new (y) int;


> Also, I think XFAIL stands for expected fail; I am not sure if it should be used for a TODO list (might be wrong though..). You could just leave the tests where they were (new.cpp) and add a note.

This is a good point, particularly because if any of the fail-tests start passing, we won't know about it. Better to use expected-warning on the incorrect results and note that they should some day be fixed. Thanks.

Jordan