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

[Eric Christopher]

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

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

Few notes on the patch:

     DI->EmitLocation(Builder,
-        cast<CompoundStmt>(blockDecl->getBody())->getRBracLoc());
+                     cast<CompoundStmt>(blockDecl->getBody())->getRBracLoc());

Separate cleanup if possible. Thanks.

+// This is to ensure that we don't generate bogus debug locations for
code inserted by ARC.
+// CHECK-NOT:  bitcast {{.*}}, !dbg

I'm all for short and simple tests, but this might be a bit obscure :)

+- (int)testFoo:(NSString *)foo {
+    // When you stop at this breakpoint, try to `po foo`. It will be nil.
+    return 1;
+
+    // When you stop at *this* breakpoint, `po foo` works. Note that
this one gets
+    // hit before the other one. This isn't what most developers expect.
+}

The comments are obviously from the testcase you got, can you instead
annotate it with something that's a bit more applicable to the debug
code gen sort of things?

+  /// \brief Temporarily suppress DebugLocations from being attached
+  /// to emitted instructions, until the next call to
+  /// SetCurrentDebugLocation() or EnableDebugLocations().  Use this
+  /// if you want an instruction to be counted towards the prologue or
+  /// if there is no useful source location.

Hrm why not assert that it hasn't been updated in the meantime?

-eric


On Mon, Apr 8, 2013 at 11:58 AM, Adrian Prantl <aprantl 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. There are a couple of bugs off of PR14330 that are
>> similar here where the gdb testsuite is checking to see where "next"
>> takes you. It's more interesting when you're looking at where next
>> takes you in something like:
>>
>> foo (bar(), baz())
>>
>> and you want to make sure that when you "next" out of baz that it
>> leaves you on the same line as foo.
>>
>> For the patch, while I'm not sure we want it, I'd like to see how the
>> functionality plays out with other similar constructs in addition to
>> just arc to see?
>
> In the CFE patch I submitted, I'm also using it to make debugging-related block setup code part of the prologue. But right now I only got the ARC and the Blocks example.
>
> -- adrian