Parser fails in unexpected way

[purpl3F0x]

Hello I have implemented a parser, and i am getting the following error.
I can't figure out why this happens, since for example, I can parse something like that successfully if ( (n < lcv) & (lcv > n) )...
This also passes f ( n % lcv == 0) {... but adding the parentheses, since to be problematic.

(I have tried adding labels to everything in cond/expr parsers, but it doesn't seem to solve the "something else" to something more indicative.)

Error: Unexpected token
    ╭─[./examples/factors.alan:15:20]
    │
 15 │     if ( (n % lcv) == 0) {
    │                    ─┬  
    │                     ╰── found == expected something else
────╯
Error: Unexpected token
    ╭─[./examples/factors.alan:25:5]
    │
 25 │     }
    │     ┬  
    │     ╰── found } expected end of input
────╯

[zesterer]

It's hard to know what's going to without knowing much about the parser's design. Are you treating parenthesised expressions as having the same precedence as atoms (i.e: literals, variable names, etc.)?

[purpl3F0x]

Thanks for your reply. Parenthesized expressions take priority.
With (descending) precedence

Operator	Suffix (operands)	priority
+ − !	prefix(1)	left
* / %	infix(2)	left
+ −	infix(2)	left
== != > < <= >=	infix(2)	none
&	infix(2)	left
|	infix(2)	left

The grammar I (try to) implement is as follows:

So "(" cond ")" is has the second to most priority int he conditions.

[purpl3F0x]

I think the problem lies in the fact that the second "(" is parsed as "(" cond ")", but it fails in the way after reaching the ==.

Printing the context in the error message seems to indicate that,

    ╭─▶ main() : proc
    ┆ ┆   
 15 │ ├─▶     if ( (n % lcv) == 0) {
    │ │            ──────┬────┬        
    │ │                  ╰───────────── while parsing this condition
    │ │                       │        
    │ ╰──────────────────────────────── while parsing this function definition
    │                         │        
    │                         ╰──────── found == expected something else
    ```

[purpl3F0x]

I found what is probably causing the issue, after removing the error recovery from the let atom =... (line 160), it seems to parse as intended. I suppose the error recovery gets in the way of (cond), rule falling back to the (expr) op expr rule.

I don't know if this intended behavior.

          .recover_with(via_parser(nested_delimiters(
               Token::ParenthesisOpen,
               Token::ParenthesisClose,
               [(Token::BraceOpen, Token::BraceClose), (Token::BracketOpen, Token::BracketClose)],
               |_| (ConditionAST { kind: ConditionKind::Error, span: Span::new(0, 0) }),
          )))

[zesterer]

It is intended behaviour, although admittedly not always desirable behaviour. Chumsky will prefer branches that result in fewer errors, but the exponential explosion of possible parse paths means that the parser may overly eagerly commit to a recovery pattern, missing an alternative valid parse. It's important to have error recovery occur as high up the stack as you reasonably can, and to not be overly general, so that the parser gets the opportunity to try all valid approaches to parsing the syntax before falling back to recovery.

[purpl3F0x]

I see. Thank you for the explanation.