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. ...
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.)
Disregard previous comment. I thought we were talking about the JS parser.
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).
(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?
I think the bug was fixed long time ago. Any confirmations?
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.
(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.