Re: adding support for column numbers

[Zack Weinberg <zack at rabi dot columbia dot edu>]

On Wed, 13 Jan 1999 17:12:59 -0800, Per Bothner wrote:
>> This scheme seems reasonable at first sight.  I am not certain whether there
>> is any such thing as compatibility here: suppose code unaware of column
>> numbers is downstream, data-flow-wise, of code aware of them; then it will
>> interpret the combined field as a very large line number.
>
>One of the compatibility "features" is that this change should not effect
>front-ends that do not column numbers.  So we can debug this feature
>in the context of the Java front-end (or a cpplib-enhanced C front-end)
>without worrying about other front-end.  I.e. it is not an all-or-nothing
>change, so we can make the change incrementally.

I see.  So the back end has to be changed all at once, but languages can be
done later.

>> One change I haven't yet made
>> but plan for the near future is that the library interface (cpp_get_token)
>> will report line, column, and file info for each token directly, instead of
>> inserting #line directives into the output.
>
>An alternative is a call-back-interface:  The compiler calls a cpplib
>function when it needs to know the position.  (However, that is rather
>different from gcc's existing lineno-always-available interface.)

This is what we have now (cpp_buf_line_and_col).  I could do it either way,
the always available model fit better with some ideas I had for macro
expansion is all.  If gcc doesn't need line numbers very often, the callback
model might be more efficient.  Besides error messages and debug info, what
needs line numbers?

zw