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

Parser gets stuck in an endless loop with an unmatched closing parenthesis #134

Open
LhKipp opened this issue Feb 15, 2025 · 1 comment · May be fixed by #135
Open

Parser gets stuck in an endless loop with an unmatched closing parenthesis #134

LhKipp opened this issue Feb 15, 2025 · 1 comment · May be fixed by #135
Labels
bug Something isn't working

Comments

@LhKipp
Copy link

LhKipp commented Feb 15, 2025

Describe the bug

Hi,

thank you for developing this tree-sitter grammar 🙏🏻 👍🏻 . It works great, except for one annoying case.

To Reproduce

The parser runs into an endless loop for the following code (note the unmatched closing ) after int:

type MyType =
    { v: int }

    member this.MemberFunc x : int) list = [ 1 ]

Debug logs return the following:

> npm run generate
> npx tree-sitter parse [path-to-bad-code] -d 2> debug_out.txt
<CTRL-C> # parse will never end as it runs into an endless loop
> cat debug_out.txt
...
recover_to_previous state:6095, depth:5
process version:1, version_count:3, state:5646, row:3, col:34
lex_internal state:158, row:3, column:34
  consume character:')'
lexed_lookahead sym:), size:1
reduce sym:long_identifier_or_op, child_count:1
reduce sym:identifier_pattern, child_count:1
reduce sym:_pattern, child_count:1
detect_error
process version:2, version_count:3, state:6095, row:3, col:35
lex_external state:43, row:3, column:35
  skip character:' '
lex_internal state:145, row:3, column:35
  skip character:' '
  consume character:'l'
  consume character:'i'
  consume character:'s'
  consume character:'t'
  consume character:'l'
lexed_lookahead sym:identifier, size:5
detect_error
resume version:0
skip_token symbol:)
process version:0, version_count:2, state:0, row:3, col:35
lex_external state:1, row:3, column:35
lexed_lookahead sym:_dedent, size:0
recover_to_previous state:6095, depth:5

The parser recovers to state 6095, runs into an error, recovers to state 6095, runs into an error ...

Expected behavior

The parser does not run into an endless loop.

** Environment (please complete the following information):**

OS: Linux
Grammar version: Commit ad824de

@LhKipp LhKipp added the bug Something isn't working label Feb 15, 2025
@LhKipp
Copy link
Author

LhKipp commented Feb 15, 2025

The issue seems to be with the error handling in scanner.h. The parser doesn't get stuck, when not returning DEDENT/PREPROC_END tokens in the error_recovery case.

@@ -132,18 +132,6 @@ static inline bool is_bracket_end(TSLexer *lexer) {
 
 static bool scan(Scanner *scanner, TSLexer *lexer, const bool *valid_symbols) {
   if (valid_symbols[ERROR_SENTINEL]) {
-    if (scanner->indents.size > 1) {
-      array_pop(&scanner->indents);
-      lexer->result_symbol = DEDENT;
-      return true;
-    }
-
-    if (scanner->preprocessor_indents.size > 0) {
-      array_pop(&scanner->preprocessor_indents);
-      lexer->result_symbol = PREPROC_END;
-      return true;
-    }
-
     return false;
   }
 

LhKipp added a commit to LhKipp/tree-sitter-fsharp that referenced this issue Feb 15, 2025
LhKipp added a commit to LhKipp/tree-sitter-fsharp that referenced this issue Feb 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
1 participant