search

SmaCCRefactoring / SmaCC

Smalltalk Compiler Compiler : a parser generator
Other
32 stars 15 forks source link

Possible Shift/Reduce conflict not being warned #56

Open hscrocha opened 6 years ago

hscrocha commented 6 years ago

I was doing some refactoring on the SolidityParser grammar rules to generate a better AST. In the current version, there is an expression rule that handles almost everything and I am trying to refactoring into different rules.

In the refactored rules, two seem to be in conflict because the parser always favors one over the other (even when the tokens received should parse the other rule), which causes parsing errors. However, SmaCC is not showing conflicts messages.

I contacted Jason and he thinks it might be a "Shift/Reduce conflict". The main problem is SmaCC not showing any messages on the possible conflict.

ThierryGoubier commented 6 years ago

Hi @hscrocha , can you debug with the SmaCC debugger and list the states, stack and possible actions at that point?

Is that grammar a glr grammar?

hscrocha commented 6 years ago

I am not using the glr directive. The grammar supposed to be LR(1) (I performed some transformations on it to be LR).

I have attached the screenshot of the debugger on the point of the error. Based on the Possible Actions the parser is inside the "VariableDeclarationRule". Instead it should be in the "IndexAccess" and/or "AssignExpression".

screen shot 2018-04-11 at 11 23 37

ThierryGoubier commented 6 years ago

From your exemple, I would be Ok with the reduction as an array declaration so far (unless you have pre-defined your bytesResult array) (and that doesn't say if you won't reduce it later as an assignment, at the end of the line).

But that may means that I don't have enough information.

hscrocha commented 6 years ago

That is the point where the parser throws an error for the "=" token.

Syntactically speaking, "id [ id ] = id" (the same as in the example) is an assign expression with an array access. However, the parser is throwing an error at the "=" because it expects the next token to be "memory", "storage", or "id" (based on the possible actions).

That is the variable declaration rule which is similar but have an extra "id". For example, a variable declaration could be "id[ id ] id = id ".

It is possible to differentiate both rules based on the third token (if it is an "id", "memory", or "storage" it is a declaration, otherwise it is an ArrayAccess). However, the parser is always favoring the variable declaration and not using the ArrayAccess.

My main problem is, SmaCC does not show any conflict messages on the grammar. Even though, it appears to be a classical shift/reduce issue.

I can send the grammar and the test files privately, if you prefer.

ThierryGoubier commented 6 years ago

Sending the files would make the process a lot easier. I can see what you're pointing out, but the shift/reduce conflict doesn't seems to be there (and, anyway, the parser generation would choose shift, not reduce).