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

[Eric Christopher]

On Tue, Apr 23, 2013 at 9:53 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
> On Apr 23, 2013, at 6:54 AM, Eric Christopher <echristo at gmail.com> wrote:
>
>> Hi Adrian,
>>
>> Basically I was thinking earlier that this shouldn't be any different
>> than the cleanups being emitted from a scope and you've only changed
>> arc and blocks here. I understand that the code you have is very
>> applicable to the use case of arc and blocks, but I want to make sure
>> that it'll work for the rest of codegen as well.
>
> To make sure we are on the same page, can you clarify what you mean by “the code you have”? The DisableDebugLocation interface?
> I’m unclear whether you are asking if using DisableDebugLocations() will work for other use-cases as well, or if you are asking if disabling debug locations is the right thing to do.
>>

I'm saying that it seems the code is similar in function and style and
should use the same type of code yes. :)

>> Also if you look the cleanups are currently associated with the end of
>> the block, what's going on that we end up stopping on the particular
>> arc code at the end of the block first? Is it perhaps not being
>> associated with a statement that makes sense?
>
> Yes, that’s due to the way we keep track of debug locations in CurDbgLocations. They are emitted while processing the closing lexical scope and thus get the debug location of the closing brace.
> If you feel more comfortable with it we could also change the location to the beginning of the scope rather than disabling it altogether, but my personal feeling is we shouldn’t.
>

Not sure what you mean, I'm curious why the arc code is getting line
information associated with the end of the block even at the
beginning? Same with blocks. (To be fair I didn't implement that front
end part so I'm relying on you to know since you're adjusting it :)

-eric