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

[John McCall]

On Apr 8, 2013, at 12:03 PM, Adrian Prantl <aprantl at apple.com> wrote:
> On Apr 8, 2013, at 11:30 AM, John McCall <rjmccall at apple.com> wrote:
>> On Apr 8, 2013, at 11:06 AM, Eric Christopher <echristo at gmail.com> wrote:
>>> On Mon, 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?
>>> 
>>> Pretty much. It's analogous to the same when we're looking at
>>> cleanups, etc. I think this is going into the realm of "opinions on
>>> behavior" here.
>> 
>> Is 'next' driven completely by line table information, or is there some
>> way in DWARF to more explicitly say "this is a point that 'next' should
>> stop at"?
> 
> The line table contains "is_stmt" flags to mark interesting locations where the debugger may stop. According to the DWARF standard it's not necessarily a source-language statement though. Function calls inside of expressions or the "," operator are probably good examples of where the debugger might stop even though its not technically a statement.

Okay.  I'm okay with following your judgment here about the right way of
modeling this.

John.