On Fri Jan 03 2014 at 4:00:30 PM, Adrian Prantl <[email protected]> wrote:
> > On Jan 3, 2014, at 15:53, Eric Christopher <[email protected]> wrote: > > > There's not enough information in the commit message, the comments, or > the test cases to know what's broken or fixed here. Why is forcing the > block the correct solution here? What is it working around? > > > > > > Let’s use this as an example: > > > ============================================================ > ================== > > --- cfe/trunk/test/CodeGenObjC/arc-linetable.m (original) > > +++ cfe/trunk/test/CodeGenObjC/arc-linetable.m Fri Jan 3 17:34:30 2014 > > - (int)testNoSideEffect:(NSString *)foo { > int x = 1; > return 1; // Return expression > } > > Before this fix, a user would set a breakpoint at the return expression > and then attempt to print x and it would fail, because the instruction that > is at that line would be in the DW_TAG_subprogram lexical scope (instead of > the lexical scope of the function body compound statement which contains x). > I'm confused by this - Clang doesn't emit a separate lexical scope for the top level compound statement of a function... > > Since the compound statement is ended before we emit the cleanups and > return block those instructions end up in the wrong scope. > > -- adrian > > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
