Bug 6380 – bison reports conflicts in CSS parser

• Component: CSS
• Status: RESOLVED FIXED

[Ricci Adams]

Upon checking a change to the JavaScript parser, I noticed that the CSS yacc file was reporting 37 shift/
reduce conflicts and 4 reduce/reduce conflicts.  Excerpt from build log below.

...
/bin/sh -c bison\ -d\ -p\ cssyy\ \"$INPUT_FILE_PATH\"\ -o\ \"$DERIVED_FILE_DIR/$INPUT_FILE_BASE.cpp
\"
cat\ \"$DERIVED_FILE_DIR/$INPUT_FILE_BASE.cpp.h\"\ \"$DERIVED_FILE_DIR/$INPUT_FILE_BASE.hpp\"\ >\ 
\"$DERIVED_FILE_DIR/$INPUT_FILE_BASE.h\"\ 2>\ /dev/null\ ||\ echo\ -n
/Volumes/Home/Projects/WebKit/WebCore/khtml/css/parser.y contains 37 shift/reduce conflicts and 4 
reduce/reduce conflicts.
...

[Geoffrey Garen]

Is this a recent behavior change? (I checked in a change to the lexer on 1/4. Previously, I didn't think we 
had any conflicts.)

[Geoffrey Garen]

Disregard previous comment. I thought we were talking about the JS parser.

[Darin Adler]

When I removed all the conflicts from the JavaScript grammar, I took a lot at doing it for the CSS grammar 
too. One of the biggest challenges is the curious handling of whitespace (done because whitespace is 
significant in selector syntax, but could be done differently).

[Christopher Jerome]

(In reply to comment #0)
> Upon checking a change to the JavaScript parser, I noticed that the CSS yacc file was reporting 37 
shift/
> reduce conflicts and 4 reduce/reduce conflicts.  Excerpt from build log below.
> 
> ...
> /bin/sh -c bison\ -d\ -p\ cssyy\ \"$INPUT_FILE_PATH\"\ -o\ \"$DERIVED_FILE_DIR/
$INPUT_FILE_BASE.cpp
> \"
> cat\ \"$DERIVED_FILE_DIR/$INPUT_FILE_BASE.cpp.h\"\ \"$DERIVED_FILE_DIR/$INPUT_FILE_BASE.hpp
\"\ >\ 
> \"$DERIVED_FILE_DIR/$INPUT_FILE_BASE.h\"\ 2>\ /dev/null\ ||\ echo\ -n
> /Volumes/Home/Projects/WebKit/WebCore/khtml/css/parser.y contains 37 shift/reduce conflicts 
and 4 
> reduce/reduce conflicts.
> ...

I Have noticed this too, I have seen shift/reduce reduce/reduce conflicts for a while now. It is still the 
same. Also why are we not using bison 2.x.x on OS X? is there a particular 'technical' or engineering 
reason for this?

[Robert Blaut]

I think the bug was fixed long time ago. Any confirmations?

[Alexey Proskuryakov]

CSSGrammar.y has 49 shift/reduce conflicts now, which are silenced with an %expect. Assuming we have no reduce/reduce conflicts, I think that this can be closed - shift/reduce ones do not necessarily indicate real bugs.

[Robert Blaut]

(In reply to comment #6)
> Assuming we have no reduce/reduce conflicts, I think that this can be
> closed - shift/reduce ones do not necessarily indicate real bugs.
> 

Done.