This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: stage1 bootstrap failuer to build gcc.3.3: cppfiles.c:1168: error: parse error before ']' token etc.
On Wed, Sep 11, 2002 at 10:32:04PM +0100, 'Neil Booth' wrote:
> Zack Weinberg wrote:-
>
> > > What about quotes?
> >
> > Ugh, I forgot all about quotes. I guess they're another case again,
> > or a state flag.
>
> The hardest quote of all is '<' since you need context. Lexing ISO C
> is really quite painful, the more you think about it 8-)
No kidding.
> I figure that if we made a token's "col" mean "logical character on
> a physical line", we could have a fairly simple loop that understands
> trigraphs that selects the right point. If, in the caret line, we replace
> every character of the original line with a space (except tabs) we will
> get the same location for output (with some handling of multibyte chars
> when we support them).
I'm not sure I understand the context in which you propose this
solution. Can you expand a bit?
> > It occurs to me that one good reason to keep the complete text of all
> > files around forever is to facilitate generating caret diagnostics; we
> > may want to do that well after we're done with any given logical line.
>
> That one possibility, though I tended to think that we should treat
> diagnostics as the slow path, and so taking the hit of re-reading
> the file if necessary would be OK.
Yes, diagnostics are definitely the slow path. If we're going to be
rereading the file we might want to consider stashing byte offsets for
purposes of doing lseek() to get back there. Except that may not work
right on VMS.
> Ugh. I really don't think there is a clean solution to this mess,
> certainly not one that is simultaneously efficient.
It occurs to me that the prime difficulty with reading the file in
chunks, independent of whether we have a prescan pass, is the (common
but not normal) situation of having a line cross a chunk boundary. We
could deal with that by scanning backward from the end of the chunk
for the last newline. Put the limit pointer there. Then we only have
to check the limit pointer at newlines, and when we hit it we can just
copy the trailing text down to the front of the buffer and keep
reading.
If the file has a single line longer than the chunk size we have to
resize the buffer, but we'd have to do that anyway.
zw