Order of alternatives has an impact on common lookahead prefix

[luan-xiaokun]

Hey guys, I'm trying to get a better understanding of Langium's handling of common lookahead prefixes, and then I came across the following interesting thing.

Suppose an integer INT and a range INT .. INT are both constants, and it is clear that there is a common prefix INT. The following rules are accepted by Chevotain, but if the order of rule call and the assignment is exchanged, then an error is reported (by Chevotain) complaining about the common lookahead prefix.

It seems that the order of alternatives has an impact on common lookahead prefix, right? I'm not quite sure if this is a feature or an issue.

Constant:
    RangeConstant | value=(ID | REAL | SWORD | UWORD | INT | BOOL);

RangeConstant infers Constant:
    lower=INT '..' upper=INT;

[msujew]

Hey @luan-xiaokun,

yeah that's a feature. Chevrotain is heavily optimized for parsing performance and skips alternatives with shorter prefixes while parsing. This is documented here. Note that we will switch to ALL(*) with Langium 1.0, which alleviates this issue. The parser will then always choose the longest matching alternative.

[luan-xiaokun]

I see, thanks for your answering! That's a new feature to learn (I should have read the document more carefully), though this new feature will soon become an old one :)

[msujew]

Note that I've just finished the implementation here :)