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.


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-)
 
> That might kick the complexity up to the point where it's not worth
> it.

That's the conclusion I came to when I tried it.  What we have now is
not too bad I think; it just needs some tweaks.  However, having a
"sanitized" source line is nice in that you can have each token point
directly to its spelling.  However, I'm not sure the complexity it
entails is any improvement over the current situation.

> That's what the annotations on the side are for.  They're basically a
> list of reverse transformations that take you from the logical line to
> the set of physical lines it was composed from.

Yup.  I tried that once, but I couldn't convince myself that the
overhead was worth it.

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).

> 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.

Ugh.  I really don't think there is a clean solution to this mess,
certainly not one that is simultaneously efficient.

Neil.


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