Comment by cb321

Our exact context here is not just column numbers, but also about backslash line continuations joined by the C preprocessor. That makes the #line directives emitted refer to columns within a (large) "virtual line assembled by the tooling", not an "actual source" coordinate.

So, a column number would not be very meaningful to a programmer (relative to some ';' or '{}' expressional label leveraging internal language syntax/bracketing which would definitely still be a bit to muck about with). As per my Lisp mention, it is really be a >1 dimensional idea, and there are various ways to flatten/marshal that parse tree. "next/over" and "step/into" are enough "incrementally/dynamically/interactively" to build up that 2d navigation, but also harder to work with "cumulatively" and with more complex than lisp grammars. Maybe most concretely, how "subexpression numbers" (in addr2x or other senses) are enumerated might still be a thing programmers need to "learn" from their "debugger UI".

Another option might be to "reverse preprocess it" or maintain forward-meta-data to go from the "virtual line column number" back to the "true source (line,column)".

I don't mean to discourage you, but just explain more what problem I meant to refer to by "how to label it" and highlight limitations of your new test. { But many are probably limited somehow! :-) }