Re: cpplib: simplify callbacks, reduce exposed interface

["Zack Weinberg" <zackw at Stanford dot EDU>]

On Wed, Nov 29, 2000 at 06:03:38PM +0000, Neil Booth wrote:
> 
> What do you want to do there?  Should we not allow -include with
> -fpreprocessed?  (Sounds like a good idea to me).  Regardless, it will
> cause problems because the output of a file preprocessed with -include
> will have the first -included file as the line marker at the top.

Just about everything should be shut off by -fpreprocessed: -include,
-imacros, -D, -I, ...

We used to be able to generate # lines for the main input and each
-include file as it was pushed.  If we can get the callbacks and
output set up early enough, that might even still work.

> Another thing - how about raising a warning or maybe even an error in
> cpp if we meet a # line without the -fpreprocessed flag?

I'd support this, and also removing the ability to specify trailing
flags on #line.  As you say, it can probably cause segfaults and the
like.  It used to be useful to write #line "foobar" 3, but now we have
#pragma GCC system_header for that.  

(#line "foobar" 3 4 and/or #pragma GCC implicit_extern_c are not
necessary - if you can tweak a file to put that in, you can just as
easily stick in an extern "C" wrapper.)

> > we don't call cb_change_file for the second line, so lineno is
> > incorrect when we call cb_change_file for the third line, so we store
> > the wrong number in the input_file_stack.  I suppose this delayed
> > notification works in other situations because we always update lineno
> > in c_lex (and blame it on C++)
> 
> :-)  I think Zack might have had something to do with that...

...
> > Also, lex_lineno seems useless; why not just update lineno directly?
> 
> Dunno.  I haven't changed the logic that was there before; either Zack
> put it there or it's been there for a long time.

Yes, I did that back in August.  cp/spew.c messes with lineno (it
defers parsing of certain constructs till potentially much later in
the file, but we still need to get their line numbers right).  So
c-lex.c needed its own private idea of the line number so it didn't
get thrown off.  lex_lineno was needed back when we still had a
separate front-end lexer; it kept track itself.  Now we should be able
to rely on cpplib's idea of the line number, but we still do need to
keep updating the global lineno.

zw