^ this is a detail which boggles my mind. why are our debuggers still line based? they're clearly not in every respect since you can basically always 'step in'to an && sub-expression, but nothing displays progress as you step through such things, nothing lets you put a breakpoint at some sub-expression, nearly every feature of every tool is delineated by lines as if they're the important part of a program.

Because something you do relatively early in the compiler is throw away all of the structure of the source, including flattening nested expressions into a linear IR. Mapping back to line numbers in the debugger is a bit hacky to begin with, and mapping back in an even more fine-grained way would be more complex still.

Both line and column information are completely carried through the process, and put into debug info, these days.

It's not hacky, it's actually completely well structured. Even debugging info for C/C++ macros is there and done properly.

None of this is new. DWARF2 (or 3 or 4), the standard debugging format for all non-MS compilers, has been able to do this well since 1993.

It's hacky in the sense that it's somewhat ad-hoc the manner in which line/column information makes it through from the source text, through the intermediate representation and optimizations, into the generated code and debug information.

In Clang/LLVM, for example, nodes are annotated with debug information using LLVM's metadata system. However, it is strictly optional for any given transformation to preserve the metadata on IR nodes. So what makes it through after optimizations is kind of a "best effort" affair.

But this is not ad-hoc at all. This is how it is deliberately designed so it degrades gracefully depending on what optimizations you choose.

Not all compilers even really degrade. GCC does post-hoc variable tracking (and thus is mostly unaffected by optimization except when values are optiized out completely). For declarations and statements, the info is always on the declaration, so it won't be lost.

Both compiler guarantee that at -O0, all debug info will be kept.

True (currently, I see no reason this is a necessary step), but that suggests you could perform trivial expansion of lines like `if (a.what() && b == c && (d == f || d < 5))` into multiple lines like you see in this article, and then use the exact same hack to get those pseudo-lines into the final stages, and into your debugger. You could even explode each piece into extra variables, so you can see the results of `a.what()` without re-evaluating it.

Honestly, even if you had to hit an 'expand this statement' button in your debugger to see `if x() && y()` spread into:

  x_val = x()
  if x_val
    y_val = y()
    if y_val
      ...

it would completely remove the necessity to write strange things to get around this limitation. Why do we have compilers and a huge variety of languages if not to stop writing strange things unnecessarily?

Even more beneficial, it would give you a much better idea of what, in fact, the computer thought you meant. Seeing a complex nested structure flattened out would give you a more visual indication of what's going on, allowing you to spot misunderstandings earlier.

I don't think it's any harder to carry line-and-column annotations through the compilation process than it is to carry just line annotations. In fact many compilers do. Of course your debug information gets larger, but that's not usually a problem during development.

On the other hand, an optimizing compiler already makes it pretty hard to single-line-step through a program (what with reordering, CSE, and more sophisticated transforms). Single-expression-stepping would be an even more difficult "debugging illusion" to provide.

So let's separate out the producer and consumer.

On the consumer side, knowing where you are is actually the least hard problem in optimized debugging, compared to things like tracking variables that got split up into multiple disjoint registers, or part in register/part in memory, etc

As for where you are, the line table already will tell you that the column number changed on pc address advance, but line number did not. Thus, you know that you moved an expression, but not a line.

GDB doesn't happen to support this, and simply looks steps until line number change.

But it's not fundamentally hard from the debugger perspective.

On the producer side: When it comes to knowing where you are, you know you can't produce a 1-1 mapping, so you don't try. You can of course, properly present inlined functions as if they were function calls, and gdb will even do this. But there are times when lines or expressions were merged, and there simply is no right answer.

With visual studio and c# you can put a break point at a certain point in many expressions and while in the debugger you can have it evaluate expressions individually when hovering with the mouse.

Stack traces, however, are still line based and thus if an exception occurs (like null reference) you only get the line, not the statement.

Not all debuggers are line-based. Many of LLVM's tools give descriptive errors ("expressive diagnostics").

Here's an example of gcc versus clang (a "frontend" for LLVM):

  $ gcc-4.2 -fsyntax-only -Wformat format-strings.c
  format-strings.c:91: warning: too few arguments for format
  $ clang -fsyntax-only format-strings.c
  format-strings.c:91:13: warning: '.*' specified field precision is missing a matching 'int' argument
    printf("%.*d");
              ^

LLVM is does some cool stuff :). Some other nice examples are at http://clang.llvm.org/diagnostics.html.

That's not a debugger though; that's a compiler.

All of the debuggers I've seen are line based with the option of single stepping through assembly.

Hopefully the LLDB people will be able to modernize debugging to the degree that the clang guys have modernized error messages, but that still remains to be seen.

Given that LLVM is way behind on producing good debug info compared to GCC, i don't think LLDB is going to improve as quick as one would like.

To be fair, that page is severely out of date, and gcc 4.2 was released six years ago. An updated comparison is here: http://gcc.gnu.org/wiki/ClangDiagnosticsComparison

Anyway, those are compiler warnings rather than after-the-fact debugging. I don't think LLVM's debugger, lldb, does any better in this case.

Very interesting point! There is an argument that lines are a unit of human comprehension and complicated expressions should be broken onto different lines already, as a matter of readability. It makes some sense to let the granularity at which you debug reuse the granularity at which you read.

If you're debugging though, presumably there's something you don't understand, so a debugger should be more granular than what you normally deal with since reading wasn't enough. In many ways they are, since you can check other things in scope (or any parent scope) which is not always visible in source (e.g. a callback has multiple stack entries outside the code that defined it, even if inline).

Gdb for g++ may be; msvc for c# is not! Gdb usability and performance is a (THE) major shortcoming of the gnu tool chain.

I've worked with debuggers that allow you to step the short-circuit operations.

That said, a huge cascade of them is something I try to avoid. Two or three, okay. Nine or ten, break it up and make it clear and readily debuggable.

This also makes individual conditions slightly easier to comment out.

And yank/cut/copy, and re-order, and type-over, and... I have developed similar habits after using line-based editors. This is very easy code to modify. (Notice the return type on a line all its own.)

Exactly. You could easily consider this to be defensive code in a similar way as always using 'break' with the last case of a switch-case is defensive.

I hadn't considered this before... interesting!

Ouch. I'm pretty sure that the compiler I worked on 22 years ago could stop at sequence points, e.g. after the evaluation of the LHS of && and ||. (OK, actually it was a superset of those, called "gesornenplatz points" in-house, but that's another story.)

Ignoring the "no space after if/while/for" issue, I'd suspect that code to not have been the author's intent if I just came across it.

Thought the same. If I need three && in an if condition, I nest (although I add brackets, I prefer having them). It makes easier debugging, easier reading and in case of need they are a good place to put some printfs