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

Remove error recovery handling in scanner.h causing parser to get stuck | fix #134 #135

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

LhKipp
Copy link

@LhKipp LhKipp commented Feb 15, 2025

No description provided.

@LhKipp LhKipp changed the title Remove error recovery handling in scanner.h causing parser to get stuck Remove error recovery handling in scanner.h causing parser to get stuck #134 Feb 15, 2025
@LhKipp LhKipp changed the title Remove error recovery handling in scanner.h causing parser to get stuck #134 Remove error recovery handling in scanner.h causing parser to get stuck | fix #134 Feb 15, 2025
@LhKipp LhKipp force-pushed the fix-parser-stuck-by-removing-error-handling branch 2 times, most recently from e667579 to 2d77b97 Compare February 15, 2025 17:28
@Nsidorenco
Copy link
Member

Hi @LhKipp,

Thank you for helping make the grammar more stable! It appears the recent update to tree-sitter broke the CI so I have reverted the update.
Could you please rebase this PR onto main and re-generate the grammar?

@LhKipp LhKipp force-pushed the fix-parser-stuck-by-removing-error-handling branch from 2d77b97 to 6901712 Compare February 17, 2025 19:15
@LhKipp
Copy link
Author

LhKipp commented Feb 17, 2025

Could you please rebase this PR onto main and re-generate the grammar?

Sure. The change set looks much better now :)

@Nsidorenco
Copy link
Member

Hi @LhKipp,
Sorry for taking so long getting to this!

I'm wondering if there would be another way to handle the looping in this case, where we could change the production rules instead?
The reason for the error recovery code is to enable better parsing of partial statements, e. g:

match x with
|

would still be able to parse as a match statement even though it is not a syntactically correct match statement.
If we flat out remove the error recovery we would negatively impact the grammar in other areas.

@LhKipp
Copy link
Author

LhKipp commented Mar 6, 2025

Hi @Nsidorenco,

Sorry for taking so long getting to this!

No worries. It didn't felt long to me :)

I'm wondering if there would be another way to handle the looping in this case, where we could change the production rules instead?

There maybe is. I am sorry to tell you, that I neither have the tree-sitter knowledge to know the solution, nor that I want to spend my time and energy on this problem (now). If you feel like this PR is a regression overall, feel free to close it or move it into draft. I won't be offended.

For me this change made the grammar usable. I am using Neovim, which apparently runs the tree-sitter parsing on the main-loop (and not async), so if the grammar runs into an endless loop, so does the editor and feels "frozen". I understand other editors can behave differently and then it's not so much of an annoyance.

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

Successfully merging this pull request may close these issues.

Parser gets stuck in an endless loop with an unmatched closing parenthesis
2 participants