Patch to improve cpplib's C++ support
Mon Jul 12 00:54:00 GMT 1999
>>>>> Zack Weinberg <firstname.lastname@example.org> 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?
More information about the Gcc-patches