This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y
- From: Ziemowit Laski <zlaski at apple dot com>
- To: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Cc: gcc-bugs at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Wed, 29 Jan 2003 17:44:10 -0800
- Subject: Re: GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y
On Wednesday, Jan 29, 2003, at 16:54 US/Pacific, Joseph S. Myers wrote:
On Wed, 29 Jan 2003, Ziemowit Laski wrote:
What does "Neil's parser" refer to, exactly? I apologize for being
out of the loop on this...
The recursive descent C parser Neil Booth is writing.
Ok, thanks. So this will be separate from Mark's C++ parser? I kind of
thought it would be nice if we could eventually teach the
recursive-descent C++
parser how to handle C and Objective-C (and thereby get Objective-C++
for free
-- well, almost). This way, we could wind up with my beloved Grand
Unified
Front-End (or GUFE). :-) Has this been considered/explored?
As far as ObjC conflicts breaking the C grammar, this is possible iff
the
ObjC-conflict-prone state can be reached from "pure C" states.
This probably holds true for some of the shift/reduce conflicts,
but these can be analyzed one-by-one and resolved via appropriate
%prec
annotations.
I'll expect such an analysis (with the conflicts being resolved
explicitly
where possible) for any merger of the existing parsers into one parser
that decides at runtime. (I don't care about conflicts only involved
in
error recovery.) C at present has just one conflict not involving
error
recovery.
What do you mean, "decides at runtime"?
There used to be a comment at the top of c-parse.in listing the
conflicts
- which was removed as very out of date and not maintained. If the
conflicts get genuinely minimised then writing a new such comment
would be
worthwhile.
The reduce/reduce conflict meaning being unable to use %expect leads
to an
increased risk that it won't be noticed (in the absence of %expect)
that
parser changes add conflicts they shouldn't. This is maintenance risk
for
C in the presence of a single parser with such a conflict.
Agreed, but this is really a limitation of Yacc/Bison (i.e., not being
able
to tell it, either via a second argument to %expect or some %prec-like
notation, that the reduce/reduce conflict is "ok").
--Zem
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477