<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 12, 2015 at 11:51 AM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently the following example:<br>
<br>
1 {<br>
2   foo(<br>
3     bar(),<br>
4     baz());<br>
5 }<br>
<br>
will get codegen’d into something like (in pseudo-IR):<br>
<br>
%arg0 = call @bar, !dbg (line: 3)<br>
%arg1 = call @baz, !dbg (line: 4)<br>
call @foo(%arg0, %arg1), !dbg(line: 2)<br>
<br>
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.<br>
<br>
The downside would be that this might break some existing debuggers’ stepping expectations.<br>
<br>
What do you think?<br></blockquote><div><br>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:<br><br>x()<br>+<br>y()<br><br>goes 1, 3, 2 - similar oddity for the user, but it's about the most accurate thing we can do, if a bit surprising.<br><br>Using the end is probably /fairly/ reliable, but also confusing:<br><br>x<br>+<br>y<br>+<br>z<br><br>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.<br><br>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.<br><br>- David</div></div></div></div>