Replies: 2 comments
-
Yes, I think you're right that the labelling behaviour in this case is inconsistent. I think the problem here is that the parser is assuming that because it couldn't even start parsing a That aside, I would advise not treating labelling as a precise, documented behaviour: exactly how chumsky does error prioritisation and generation is deliberately considered to be an implementation issue so that it can be improved incrementally without the change being considered breaking. |
Beta Was this translation helpful? Give feedback.
-
Actually –and sorry for any confusion– I used labelled definitions just for illustration, but the core question is, why |
Beta Was this translation helpful? Give feedback.
-
Trying to better understand the error reporting for empty input in general.
(Using chumsky1.0.0-alpha.6)
Based on this simple token type and parser:
With
Token::Eoi
as an explicit token in the input sequence, that is,vec![Token::Eoi]
, I seem to get the desirable behavior:that is (basically), with found=Eoi and expected="program".
However, why not a similar behavior for
expected
whenvec![]
is given as input:assert_eq!(found, &None)
in this case (which passes) seems appropriate asfound
is in terms of tokens, and there are no tokens at all in the input;expected
should still pass as indicated, but fails becauseexpected
turns out to be empty:I'd appreciate any comments/clarifications.
Beta Was this translation helpful? Give feedback.
All reactions