On Jul 28, 2014, at 9:36 , Manuel Klimek <[email protected]> wrote: > On Mon, Jul 28, 2014 at 6:27 PM, Jordan Rose <[email protected]> wrote: > > On Jul 28, 2014, at 7:56 , Manuel Klimek <[email protected]> wrote: > >> On Mon, Jul 28, 2014 at 4:01 PM, Manuel Klimek <[email protected]> wrote: >> On Mon, Jul 28, 2014 at 3:43 PM, Manuel Klimek <[email protected]> wrote: >> Some more context: >> It seems like we already need to do that when building the CFG: for the >> lifetime extended object we must not emit the destructor at the end of the >> full expression, which we currently do. >> >> And it looks like we're already trying to do that by handing BindToTemporary >> down. I'm investigating some more... >> >> Found bug, separate patch sent (although right now I think it's also still >> wrong). >> I think we need to fix how we handle lifetime extended temporaries before we >> can really do anything here - the main bug in lifetime extended temporary >> handling is in connecting the MaterializeTemporaryExpr to the right >> CXXBindTemporaryExpr (if it exists). Once that problem is solved, we can >> simple mark the CXXBindTemporary that is lifetime extended once we hit the >> MaterializeTempraryExpr in the static analyzer. > > I'd really like the CFG to be correct, not something that we have to > reconstruct correctness for in the analyzer. > > Yes, but it's currently not correct. > > We should be able to statically tell which temporary a > MaterializeTemporaryExpr is going to bind to, right? Or rather, we should be > able to tell whether or not a given CXXBindTemporaryExpr will be destroyed or > bound if it is executed. > > Yes, fully agreed, but first we have to fix how to handle lifetime extended > temporaries - the fix *is* getting that information correctly out of the AST. > I'd rather not mix this patch with a fix for lifetime extended temporaries, > and I'm not sure continuing to maintain this patch until after I fixed > lifetime extended temps is a good idea. >
Agreed. I was just objecting to "mark the CXXBindTemporary...once we hit the MaterializeTemporaryExpr in the static analyzer". It seems like we would never add a destructor for that temporary in the first place, so we wouldn't have to mark it as skipped. Or did you mean "when building the CFG"? Jordan
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
