Add the %debug directive to the .l, declare the <prefix>debug (prefix=yy by default) global int variable, and set it to 1 in main() before calling yyparse(). Make sure to run bison with --report all to print a report of the states and their transitions so you can follow the output that will be generated.
A shift/reduce conflict happens when the compiler compiler can't figure out what to do with certain token sequences. The canonical example is this:
What does "if a then if b then c else d" mean?
A. "if a then { if b then c else d }" (shift solution)
B. "if a then { if b then c } else b" (reduce solution)
"Shifting" means to push (or "shift", in parser parlance) the nonterminal symbol (in this example, the else block) into the symbol stack. This will later cause the parser to treat the then block and else block as part of the same if statement.
"Reducing" means to just reduce the token string as soon as possible. In the example, "if b then c" is a complete if statement, so it can be reduced immediately.
Bison solves shift/reduce conflicts by shifting. This is usually what was intended, but you should study each conflict carefully, as they usually indicate some design issue in your grammar.
The third production rule for 'file' is a s/r conflict. The string "a.rsc b.rsc c.rsc" is a 'file' that can be assembled from smaller 'file's in different ways:
* "((a.rsc) (b.rsc)) (c.rsc)"
* "(a.rsc) ((b.rsc) (c.rsc))"
The proper way to make lists in Yacc/Bison is
1 2 3 4 5
|
list_element: /*...*/;
possibly_empty_list: | possibly_empty_list list_element;
never_empty_list: list_element | never_empty_list list_element;
|
You have a similar problem in your definition of 'statement_list'.