LARL parser issue with multiple rules that produce nothing

I believe the following example should parse:

from lark import Lark
p = Lark("""
    a: b c d
    b: "B"
    c: | "C"
    d: | "D"
""", start='a', parser='lalr')
print(p.parse('B'))

I would expect it to produce Tree(a, [Tree(b, [Token(B, 'B')]), Tree(c, []), Tree(d, [])]), but instead it fails with

UnexpectedToken: Unexpected token Token(B, 'B') at line 1, column 1.
Expected: C, D

I think the generated parse table is missing reduce b for $END in state 6 - it does so for lookahead C or D, but not for $END. Curiously, it works OK if instead of epsilon producing rules for c and d I use a: b c? d?, but this is much less convenient for my usage as I will have to inspect what types are the optional arguments to the transformer method a to find out what they mean instead of just having them in the correspondingly named argument.

[erezsh]

lol that’s probably wise. If you feel like taking a crack at some of the open issues that would be great, although admittedly most of them are boring usability issues, rather than cool algorithmic bugs. (Except for the ones about Earley, but they are already on the way to be fixed)

[petee-d]

Wow, @erezsh, such time of response is simply amazing! Doing a fix of such a deeply hidden bug from issue to master within an hour is quite something. 😃 I’m very happy to say my real grammar where I discovered this (100+ lines) now works perfectly. I really love the project, the best parsing library I have seen so far, and I’ve previously been switching them like socks in my project.

I’ve heard there are exactly 2 hard problems in computer science: cache invalidation, naming things, and off-by-one errors.

BTW, would you like me to create another issue for the error reporting problem I mentioned in my last comment? It might take some creativity to fix it in a backwards compatible way, probably not something to bundle with another fix.