Re: Patch to improve cpplib's C++ support

[Jason Merrill <jason at cygnus dot com>]

>>>>> Zack Weinberg <zack@rabi.columbia.edu> writes:

 > However, I'm working on a revised API to cpplib that is going to behave
 > differently in both the affected areas.  The big difference is that you
 > make one function call and get handed an entire line split up into
 > tokens.  You then can walk through it at your leisure.

Why a line?  The current API of getting one token at a time makes sense to
me.  I actually find it inconvenient that #-directives are treated as one
big token rather than a series of tokens like everything else; it means
that I can't always rely on cpplib pre-tokenization in yylex().

 > If you stack another input buffer in the middle of parsing the list,
 > it'll still be there when you come back (this is needed anyway for macro
 > expansion).  So cpp_unget becomes a pointer decrement in the front end.
 > On the flip side, you can't back up by part of a token.  cpp_unget as it
 > was in your patch would have let you do that.

No problem; it was only actually used for full tokens.

 > As for redirected_input_p, the plan is to make caller pop the buffer all
 > the time (except for macro buffers).

Huh?  Why should the frontend handle #includes?

Jason