This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ANSIfy cp/parser.c
Vladimir Makarov wrote:-
> I do believe it too. I don't want to start a flame. With my point of
> view the combined parser is reflection of the belief that nobody is
> interested in only C compiler and the most people is interested in
> C/C++. C++ started as a small extension of C and now C is a tiny part
> of C++. If this belief is not true, than the separate C front-end
> results in more manageable and reliable C front-end.
Agreed. I'm not anti-C++, I just want the best C and C++ front ends
possible.
> Do you use a compiler-compiler? If you are writing it manually (usging
> recursive functions), then how are you going to implement syntactic
> error recovery? What quality of the recovery do you can achieve this
> way?
I think reasonably good recovery is possible. Just because something
is recursive descent doesn't mean you have to make it textbook 100%
recursive descent. For example, my current expression parser unifies all
of cast-expression, unary-expression and primary-expression, but keeps
postfix-expression separate, because that makes it easy to handle a
'(', which can start 3 things: parenthesized expression, a compound
literal, or a cast. Without unification you need backtracking or
something nasty.
However, I've not seen what error recovery is like, because I'm nothing
like that far yet 8-) However, do you think the EDG front end's give
bad diagnostics? IMO they're better than any other compiler I've seen
and they use RD.
> IMHO, you can not achieve a good syntactic error recover without an
> explicit parser stack. Also I think that the current computers permit
> to implement a minimal cost error recovery now (actually the slowdown
> occurs if a syntax error is found). Such implementation needs a
> backtracking to evaluate different alternatives of the recovery.
Let's see.
> Also it is good to have C parser as an abstract component. It could use
> it not only for gcc (it might result in creation of another free C
> compiler -- it is good for gcc to have another free c compiler as a
> competitor).
Indeed. I think GCC needs competition; it's getting a bit fat and lazy.
> You can ignore these ideas and questions - it is your implementation. I
> know how front-end implementation is difficult and boring.
Au contraire, I'm finding it fun and interesting. But I've not done it
before, and I've not studied CS, so it's not old-hat to me.
Neil.