[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

Max TenEyck Woodbury <mtewoodbury at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mtewoodbury at gmail dot com

--- Comment #2 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
Grumble!

Modified testsuite/gcc.dg/cpp/line4.c to test __LINE__ use.  I think I
saw a stronger set of tests while 'googling' the problem.  I was a bit
short on understanding when I saw it, so I didn't mark it for study...

I've looked at the code that handles this.  It's in the libcpp tree.

Thw indentation is messed up.  '\t' used in many places WITHOUT consistant
tab widths.  I see spots with '\t' stops at 4 and at 8.  Indent width is
mostly 2.  Style is a bit mixed.  FOR MY OWN USE, I've cleaned this up.
The result is much more readable.

I tried a simple look-ahead hack, but no go.

Going the mild KLUGE route:  Use a special value to indicate the bad
value and emit it under special circumstances.

- define the special value CUR__LINE__ in include/libcpp.h (-1)
- modify state.in_directive to have a special value (2) when in the #line
  directive (in do_line).
- check for the CUR__LINE__ value at the end of do_line after flushing the
  tokens and use replace the special value with the current line number
  before doing the state change.
- in macro.c, __LINE__ processing, look for the special stat.in_directive
  value and return CUR__LINE__ if it has the special value.

Potential problem if someone uses __LINE__ to construct the file name.

Intrest?