Adriaan van Os wrote:
Frank Heckenbach wrote:
Peter N Lewis wrote:
It seems there is an off by one error with the "warning: unused variable" warning.
There are many off by one [token] problems with messages. I think I know how to fix them now, but it will require a new Bison version. Even worse, it seems to require a Bison bugfix first, and I don't know how long this will take. So it might get even somewhat worse in the next GPC release, but hopefully correct some time later ...
It may be interesting to note that GCC is shifting to a hand-crafted recursive-descent parser.
"Mark Mitchell of CodeSourcery has contributed a new, hand-crafted recursive-descent C++ parser sponsored by the Los Alamos National Laboratory. The new parser is more standard conforming and fixes many bugs (about 100 in our bug database alone) from the old YACC-derived parser."
See http://gcc.gnu.org/ml/gcc/2000-10/msg00573.html.
I remember friends telling me that hand-crafted recursive-descent parsers were "old fashioned", parser generators were the "real thing" ... Times may change ...
The "new thing" is actually recursive-descent parser generators, since they have the debugging benefits of recursive-descent parsers with the maintenance benefits of autogenerated parsers. See for instance ANTLR and JavaCC. But nobody's written one (yet) which can be used for applications coded in C, such as the C++ compiler.
C++ also turns out to be a horrible language to parse; it requires arbitrary (infinite) lookahead and so can't be implemented straightforwardly in most parser generators at all. The new parser uses the techique of 'tentative parsing', then deciding whether to keep the 'tentative parse' or try parsing a different way, and it nests it layers deep. There's no parser generating tool out there that can do *that* cleanly. :-/
Certainly parser generators are easier to maintain than hand-coded parsers -- for languages which they can parse. C++ happens not to be one of those languages.