I forgot to mention. When I comment out the nonsense line I get this instead
270 | rval '=' rval . [..., '}', '\n'] <--- Key point is this does
not have a ',' anymore
rvalLoop: rval . ',' rval
',' shift, and go to state
I suppose it is right to reduce and never shift?
How do I override this? I tried writing "%token OVERRIDE_PREC" and "%left
OVERRIDE_PREC" at the bottom of my %left/%right directives. Then I used
%prec OVERRIDE_PREC on | rval '=' rvalLoop and in rvalLoop. But it appeared
not to have worked.
On Mon, Dec 9, 2013 at 11:22 PM, Adam Smalin <acidzombi...@gmail.com> wrote:
> I don't fully understand this but i'll try to describe it
>
> My rules are similar to the below
>
> body:
> recursive-expr //rval + rval, rval = rval, etc
> | rval '=' rvalLoop
> // | rval ',' rval '$' '$' '$' //nonsense here to show the problem
>
> rvalLoop:
> rval
> | rvalLoop ',' rval
>
> In my test file when I do "var = 5, 6" it works fine. When I uncomment the
> nonsense line my parser broke.
>
> THE CRAZY THING IS I still have 0 shift/reduce and 0 reduce/reduce errors.
>
> I searched "rval '=' rval ." in my conflict file and I see this
>
> 270 | rval '=' rval . [..., ',', '}', '\n']
> rvalLoop: rval . ',' rval
>
> Conflict between rule 270 and token ',' resolved as reduce (',' < '=').
>
> It seems to have decided to never use rvalLoop in this situation. The
> weird thing is the nonsense line has nothing to do with it.
>
> Removing the nonsense line or making ',' a higher (or lower?) than '='
> fixes the problem. The nonsense line is a real line I made into nonsense
> just to see what would happen. Changing the comma precedence order would
> break things and my real rule triggers the problem in this nonsense rule.
> The parser reports no conflicts
>
> Whats going on here? How do I fix it?
>
