[PATCH] Do not attach a debug location to code inserted by ARC / API for disabling DebugLocations

Adrian Prantl aprantl at apple.com
Mon Apr 8 11:55:42 PDT 2013


On Apr 8, 2013, at 10:40 AM, John McCall <rjmccall at apple.com> wrote:

> On Apr 5, 2013, at 5:22 PM, Adrian Prantl <aprantl at apple.com> wrote:
>> Patch for review, mostly for the IRBuilder::DisableDebugLocations() part.
>> 
>> Do not attach a debug location to code inserted by ARC --
>> it would create a spurious line table entry at the closing } of the scope.
> 
> Is this a problem?  Just that we don't want "next" to stop here?

In this particular example, what happens is as follows: Because of the way we keep track of the debug location in the backend, both ARC setup and cleanup code are associated with the closing brace (because they are emitted while closing the current lexical scope). This means that when we step through a function we may hit the closing brace first, then the return statement, and then the closing brace again.

void foo(SomeObject*){
   return 1;
} // ARC cleanup+setup

If just don't emit line numbers for the ARC setup code it will get associated with the function prologue, which is in my opinion the right thing to do. (There is no correct source line to associate it with anyway).
We can argue about the cleanup code, but my intuition is that we should only point to a line in the source code if there is actually something there to point to. If don't emit a line info for the cleanup code (as in my patch), it will get associated with the return statement.

-- adrian



More information about the cfe-commits mailing list