Recommended method for customizing parser rule error handling

[nametable]

Hi, I am looking for a way to handle a parser error in a different way. My problem is that in the language I am working on, statements end with a ; and functions end with a }. When I have a failure to parse the statement, it is possible for the AST node to end early when consuming tokens. This can cause the parser to go back up to the rule for the function as a whole, and then interpret a } as the end of the function, when instead it was supposed to be a part of some obj/array initializer (in my lang).

Here's an example similar to what I'm talking about:

prog TestProg {
    fn TestFunc() {
        // the bad syntax causes the statement (`Element`) to end early, the `"test"` and `"a test"` get interpreted as more `Element`s,  and the `}` ends the `Block`
        const old = <some bad syntax here>"test": "a test"};
        const a = 57; // gets interpreted as not in the function (`Block`), so it is not an `Element`
    } // Because no longer in function `Block`, this `}` ends the entire program

    struct Hey{ // already EOF as far as parser is concerned, so left unparsed and not referenceable
        a: string
    }
}

with some example grammar that is similar to my situation:

Element:
    IfStatement 
    | WhileStatement 
    | VariableDeclaration ';'
    | Expression ';'
;

Block:
    '{' elements+=Element* '}';

Is there a good way to customize the parser to be able to handle errors differently? I looked into created a new class based on LangiumParser (or from BaseParser directly), but some functions could not be overwritten such as rule, getRule, subrule because the types they use for parameter/return are not exported from Langium (ParserRule, RuleImpl, RuleResult).

[msujew]

Hey @nametable,

Aside from the fact that the Langium parser is pretty much closed down (as you correctly identified), we use Chevrotain under the hood, which features very limited mechanisms to customize the error recovery. So the answer is: No way to do this in the parser right now. Your best guess might be to adjust the grammar slightly to improve the out-of-the-box behavior, but this obviously isn't ideal and might not even work well.

We have an open issue for this #1742, which aims to eventually improve on this, but don't count on it being available any time soon.