On Feb 6, 2012, at 1:09 AM, Erik Verbruggen <[email protected]> wrote:
> On 31-1-12 20:20, Ted Kremenek wrote: >> Hi Erik, >> >> I know that we have been discussing changing the CFG around its handling of >> ReturnStmts, but it isn't clear to me what this accomplishes. We aren't >> looking to enforce that ReturnStmt is the last *statement* in a CFGBlock. >> The ReturnStmt in a CFGBlock currently represents binding the return value, >> not a control-flow transfer. If we want to model the ReturnStmt as a >> control-flow transfer (which is subject to debate), we should consider also >> making it a terminator (which is preceded by all the cleanup destructors). >> I'm also not certain what you mean by "this results in blocks ending in with >> a terminator statement." >> >> I don't want to put the brakes on this, but if the goal is to fix how >> destructors are represented in the CFG, I'd rather we *first* do the upfront >> infrastructure work discussed in PR 11645, and then re-evaluate, as a whole, >> how destructors are currently represented in the CFG. This all feels a bit >> piecemeal, which would be fine if we were fixing specific issues, but the >> general sense I have right now is that how destructors are currently >> represented in the CFG is possibly very different from where we need to go >> once the infrastructure work in PR 11645 is done. It's also not clear to me >> what invariants this patch is trying to establish or change. > > You are right of course. The patch was in my outgoing-patch-queue for some > time, and I send it without too much thought. My fault. No worries. I think we're at the point where we are re-evaluating and re-designing some key parts of the CFG, so I think it is fine bringing up ReturnStmt in those discussions, but it should be part of a bigger picture of where we want to take the CFG. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
