http://llvm.org/bugs/show_bug.cgi?id=10805
Ted Kremenek <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #3 from Ted Kremenek <[email protected]> 2011-08-31 19:01:54 CDT --- (In reply to comment #2) > > As for the "first" statement, are you talking about the "do"? > > No, I am talking about the "this" in "this->f". > > [ B2 ] > 1: operator++ > 2: [B2.1] > 3: ++ this->f (OperatorCall) > Predecessors (2): B3 B4 > Successors (1): B1 > <snip> > Notice that Block B2 is missing the first two lines from your example: > > 1: this > 2: [B2.1]->f > > If these two lines were present, then the first statement would have a source > location. However, although the lack of source location is how I discovered > the issue, it is perhaps misleading. My apologies for not including the > actual > CFG dump in the initial bug report. > The CFG is well-formed, since the "this->f" is a subexpression of the operator call. It's not included as a "block-level expression" because the CFG isn't fully linearized. As for the missing location for 'this', I hazard to guess it isn't there because 'this' doesn't appear in your code example. Hence it doesn't have a valid SourceLocation. Not all AST nodes are required to have valid SourceLocations. Sometimes they are invalid in case where we implicitly add an AST element for semantic convenience in the AST. In this case, since 'this' was not explicitly written, it should *not* have a SourceLocation. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
