Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected behavior with error recovery mode implemented in gocc #76

Open
shivansh opened this issue May 9, 2018 · 0 comments
Open

Comments

@shivansh
Copy link
Collaborator

shivansh commented May 9, 2018

Reference

The aim of this issue is to make an attempt at explaining the behavior (mentioned in the reference above) demonstrated by error recovery implemented in gocc.

Scenario

When testing input a ; b using the error recovery example, the following output is generated -

output: [
Error in S0: INVALID(0,;), Pos(offset=2, line=1, column=3), expected one of: id error
	b
]

The valid terminal a is not available in the final output.

Reasoning

This commit adds a few debug statements demonstrating the recovery behavior. The output generated via go test -v is available here (relevant output starts from here).

When the input reaches symbol ;, the action table does not contain a valid action corresponding to the state of the stack. As a result the recovery mode kicks in and pops all the non-recovery states along with their attributes [1] (in this case a single pop is performed and a is lost [2] along with state 3). The valid recovery state which is now on the top of the stack is 1, and corresponding to this state a shift action is performed pushing the errorAttrib on stack [3] [4]. The parsing resumes normally from here.

I'm not sure whether this is the correct behavior, but this is how things appear to be happening.

I tried a lot today to somehow make the symbol a stay on stack, so that the final output will be a, error, b, but all in vain.
Comments on above are appreciated.

shivansh added a commit to shivansh/gocc that referenced this issue May 10, 2018
The following steps are performed when an invalid input symbol is
encountered -

  * In case the input reaches an invalid symbol, we save its error
    attribute and keep discarding all the immediately following error
    symbols until a valid symbol is found.

  * If the action corresponding to the found valid symbol is reduce, it
    performed. In case it is a shift, it is deferred until the error
    attribute is pushed on the stack.

  * It should be noted that the current heuristic cannot report multiple
    errors for invalid symbols occurring one after the other. If such a
    case arises, the error for only the first invalid symbol is
    reported. This is also the case with the currently implemented error
    recovery heuristic in gocc.

Updates goccmack#76
shivansh added a commit to shivansh/gocc that referenced this issue May 10, 2018
The following steps are performed when an invalid input symbol is
encountered -

  * In case the input reaches an invalid symbol, we save its error
    attribute and keep discarding all the immediately following error
    symbols until a valid symbol is found.

  * If the action corresponding to the found valid symbol is reduce, it
    performed. In case it is a shift, it is deferred until the error
    attribute is pushed on the stack.

  * It should be noted that the current heuristic cannot report multiple
    errors for invalid symbols occurring one after the other. If such a
    case arises, the error for only the first invalid symbol is
    reported. This is also the case with the currently implemented error
    recovery heuristic in gocc.

Demo
~~~~

>> go test -v

    === RUN   TestFail
    input: a ; b
    output: [
    	a
    Error in S0: INVALID(0,;), Pos(offset=2, line=1, column=3), expected one of: $ id error
    	b
    ]
    --- PASS: TestFail (0.00s)
    PASS
    ok  	github.com/goccmack/gocc/example/errorrecovery	0.005s

Updates goccmack#76
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant