GCC-3.2.2 bootstrap FAILURE: 1 reduce/reduce conflict in objc-parse.y

[Ziemowit Laski]

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