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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to