[cfe-dev] Line info for call expressions

[David Blaikie]

On Thu, Mar 12, 2015 at 11:51 AM, Adrian Prantl <aprantl at apple.com> wrote:

> Currently the following example:
>
> 1 {
> 2   foo(
> 3     bar(),
> 4     baz());
> 5 }
>
> will get codegen’d into something like (in pseudo-IR):
>
> %arg0 = call @bar, !dbg (line: 3)
> %arg1 = call @baz, !dbg (line: 4)
> call @foo(%arg0, %arg1), !dbg(line: 2)
>
> which leads to a weird debugging experience. When developers set a
> breakpoint at line 2, they don’t generally expect line 3 and 4 to already
> have executed. It sounds like a solution would be to associate call
> expressions with the location of the closing parenthesis instead, so the
> breakpoint could fall through to line 3 and single-stepping behaves as
> expected.
>
> The downside would be that this might break some existing debuggers’
> stepping expectations.
>
> What do you think?
>

This generalizes over any line table entry - currently we associate
instruction any operation with the preferred source location of the
instruction. This means something like:

x()
+
y()

goes 1, 3, 2 - similar oddity for the user, but it's about the most
accurate thing we can do, if a bit surprising.

Using the end is probably /fairly/ reliable, but also confusing:

x
+
y
+
z

if + is overloaded and you're in a backtrace which points to line 3 or 5 -
you have to figure out the precedence to know which '+' operator call you
were actually in. By using the preferred location we get line 2 or 4 and
it's obvious which plus the program is executing.

Chandler & I talked about this (offline, unfortunately) when I was making
major improvements to locations a few months ago & settled on preferred
location being the least ambiguous thing for users. Maybe there are other
perspectives we hadn't considered, though.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150312/2a4bc628/attachment.html>