cpplib: simplify callbacks, reduce exposed interface

[Neil Booth]

Hi Jason,

Thanks for the feedback.

Jason Merrill wrote:-

> Thanks, it mostly does.  However, we still need to reimplement
> the special handling of a #line directive on the first line of the
> file, in which case the given filename overrides the physical
> filename.  Currently the main_input_filename is incorrectly set,
> such that for the following testcase the static constructor function
> will be named after the filename you give it, rather than wa.C.

Good point, I hadn't thought of that.  I take it this is affecting
your C++ name mangling or something?

This brings up an interesting problem (well, assuming you consider
this type of thing interesting :-)).

-include has caused various problems recently, mainly due to the
poorly documented and enforced way we handle buffers (not to mention
the empty file optimization causing non-existent buffer headaches...).
I can see -include causing problems here too.

cpplib, since way back when I started looking at it in February, puts
the main file on the bottom of a buffer stack, and then puts any
-included files on top of it.  It then proceeds to pop these buffers
off one by one.  As a result, the first -include file comes first.

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.

Another thing - how about raising a warning or maybe even an error in
cpp if we meet a # line without the -fpreprocessed flag?  I would be
surprised if entering files with the "1" flag but not leaving them
properly with the "2" flag (or other tom-foolery) doesn't cause
segfaults in the front ends at present.  This should be caught by cpp,
but it's not quite ready to do that yet.

Thoughts?

> Playing with cb_change_file, I notice that when we have multiple #line
> directives, as in
> 
> ---
> # 1 "/home/jason/eg/gcc/crtstuff.c"
> # 58 "/home/jason/eg/gcc/crtstuff.c"
> # 1 "auto-host.h" 1
> ---
> 
> 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...

>, but in this case we don't hit c_lex
> between the directives.  Probably the simplest solution would be to
> update lineno from fc->from.lineno before pushing.

Hmm, that's odd and shouldn't be happening.  I'll look into it.

> Another question:  Why did you leave the pfile argument, when it's
> unused in all implementations?

For the same reason we use it anywhere - cpplib is re-entrant, and you
can be preprocessing mutliple files at once.  If you choose to share
callback handlers, you can tell which instance called you back.

> 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.  Tidying up the
"glue" between cpplib and the front ends is on my long list of things
to do.  I'm sure there's lots of room for improvement.

Neil.