Re: cpplib startup patch

[Zack Weinberg <zack at rabi dot columbia dot edu>]

On 12 Jul 1999 12:56:51 -0700, Jason Merrill wrote:
>>>>>> Dave Brolley <brolley@cygnus.com> writes:
>
> > OK, I see what's going on. output_line_command is called from cpp_start_rea
>d
> > before lang_init gets called. In that case the patch needs some work:
>
> > o There are some other calls to output_line_command in cpp_sart_read that
> > should might need to be changed to output_initial_line_command.
> > o An initial #line directive beginning with whitespace should be recognized
> > since the non-cpplib compilers seem to do it.
>
>It occurs to me that a better option might be to add a flag to note that
>we're dealing with preprocessed code, and just suppress the call to
>output_line_command if we are.  We should have such an option in any
>case.

Agreed; there are a number of other things that need to be turned off by
that option, too (directive recognition other than # 123 "file", macro
expansion).

Dave said something about cccp doing the same thing - that's not a bug for
cccp because one normally does not run preprocessed text through cccp again.
It's only because there's no way to turn the preprocessor _off_ in a
USE_CPPLIB front end that you see this bug.  (And that is the real bug.)

>We need the check_newline to set input_filename before we use it later in
>lang_init.  Is this the right way to get the filename from cpplib?

I think you want to look at cpp_file_buffer(&parse_in)->nominal_fname.

>BTW, why does cpp_reader have a lineno member, but not filename or colno?

You're supposed to look at the buffer to get filename, and call
cpp_buf_line_and_col() to get column and line.  parse_in.lineno is not
necessarily accurate.

>Another BTW: Under the current code, cpp_start_read queues up the the
>artificial CPP_DIRECTIVE before the frontend has asked for a token; for
>simplicity of the API, this should probably be changed so that it waits for
>cpp_get_token like everybody else.

Agree.

zw