Re: C++ lexer (GCC 3.1.1) requires knowledge of other C dialects

[Stan Shebs <shebs at apple dot com>]

Gary Funck wrote:

> -----Original Message-----
> From: Neil Booth [mailto:neil@daikokuya.co.uk]
>
> > We're slowly working on combining the C/C++/ObjC front ends into one
> > mahousive front end that handles them all.
>
> Will this new front-end still be YACC (bison) based? I've seen and heard
> about an effort to build a hand-crafted recursive descent parser. Although
> there may be some advantages to such an approach, I can see where adding new
> dialects of C might become problematic with such an approach - it may be
> difficult to verify that new language constructs do not break the parser by
> introducing the need for new look-ahead sets, etc. The advantage of using an
> automated parser genreator (like YACC, PCCTS, JYACC, etc) is that these
> programs can determine if (and where) the grammar is ambiguous, and will
> automatically generate the required (and correct) look-ahead sets.
Yacc-class generators turn out to be fundamentally inadequate for
C++, and in retrospect it looks like it wasn't such a great idea to
produce a C++ compiler as a completely separate frontend from
the C compiler - over the years there has had to be a bunch of
duplicated work, duplicated bug reports, etc.  (Could Tiemann
have been sufficiently clairvoyant?  Perhaps not...)

To be honest, support for new dialects of C has not really been a
design requirement for the GCC frontends, and I think it would be
impractical to add such a requirement, too vague to specify.  From
my one bit of experience (AltiVec extensions to C and C++), yacc
wasn't really a help anyway, because the extensions had to be context
sensitive in various ways, and the parser changes proper were the
smallest part of the support code.

Stan