This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stage1 bootstrap failuer to build gcc.3.3: cppfiles.c:1168: error: parse error before ']' token etc.


On Thu, Sep 12, 2002 at 09:05:45AM +0100, 'Neil Booth' wrote:
> Zack Weinberg wrote:-
> 
> > > 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?
> 
> Sorry I was unclear.  Any context in which we pre-scan the line removing
> trigraphs and escaped newlines.

Okay, yes, that will work.  It unfortunately doesn't help us avoid
warning about trigraphs inside comments, though.  One possibility is
that we treat trigraphs as alternate spellings except for ??/newline
(and string constants).

Or then again, maybe what we do now is good enough.

The real question is how we make this stuff play nice with character
encoding conversion.  And that also raises the question of characters
for which wcwidth() != 1.

> > 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.
> 
> Yes.  You might be able to just terminate the chunk with NUL and lex
> like we do now.  You just need to be able to back up over the previous
> token when you reach the NUL, since it might have been prematurely
> terminated.  This means you have to be careful about issuing diagnostics
> too early, in case they were caused by the premature NUL.

The idea is to have \n be the end-of-chunk marker, not NUL, which i
think actually makes life easier.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]