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

[Adrian Prantl]

Hi Eric,

On Apr 8, 2013, at 1:23 PM, Eric Christopher <echristo at gmail.com> wrote:

> So, since you didn't respond to the rest, these are the similar bugs I
> was speaking about:
> 
> http://llvm.org/bugs/show_bug.cgi?id=14498
> http://llvm.org/bugs/show_bug.cgi?id=14580
> 
> with a little bit due to:
> 
> http://llvm.org/bugs/show_bug.cgi?id=14610
> http://llvm.org/bugs/show_bug.cgi?id=14473

Great! I was hesitant to answer to the rest before I knew more about those PRs :-)

> 
> Before we go forward with this I'd like to discuss the general
> applicability here for line information.

Sure. My argument for the ARC case is that there is no sensible source line to associate calls to ARC runtime functions (that are mostly transparent to the programmer) with. 

For the ARC setup code it may be possible to use the location of the beginning of the lexical scope. I’m not convinced about the cleanup part, though. Do we really want to step through

1 void foo() {
2    return 1;
3 }

in the order 1-3-2 ? (And right now it would be 3-2-3, which is even worse).

The situation is perhaps less clear if the return statement is missing.
According to http://llvm.org/bugs/show_bug.cgi?id=14498, GCC does create an entry for the last line, but at least the lines are visited consecutively. (Is that also true if there is a complex expression in the return?)

My personal opinion would be to not emit line info if we don’t have anything to point to in the source code -- it might even reduce the size of our debug info.
Of course, not breaking the gdb testsuite would be a good argument against it. I don’t think that this would be the case for ARC, though.

> Few notes on the patch:

I made all suggested changes, thanks for the review!

-- Adrian