pigeon: Line numbers in errNoMatch
Hi Martin,
The line numbers in errNoMatch errors do not make sense to me. Any help or pointers would be appreciated.
I started to reproduce this with a minimal test case but then realized that I could use an invalid .peg file and run pigeon over it to produce the same error…
For example…
$ cat blah.peg
Output:
xxx
(yes, a bunch of newlines followed by “xxx” followed by newline).
Then run pigeon over the file to generate the parser…
$ pigeon blah.peg
parse error(s):
blah.peg:2:0 (0): no match found
Line 2 doesn’t seem to be the problem here. I must be missing something!
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 34 (2 by maintainers)
Commits related to this issue
- Add test for issue #18 with and without FailureTracking — committed to breml/pigeon by breml 7 years ago
@joshsharp I am absolutely with you regarding
but as mentioned in by @mna in reddit thread, it is not a trivial task to return something more useful automatically. I think, there is some room for improvement, especially if I compare to the error messages provided by pegjs. Any help to improve the error reporting or to investigate, how the error reporting is done e.g. in pegjs, would be appreciated.
Yes, I think, that the current behavior in parse is the correct behavior due to the built in backtracking in PEG. If you run pigeon with the
-debugflag set, you will see, that the parser performs a backtracking until the back to the very first rule, where the parser has no more options to move forward, which results in theno match founderror. That being said, I am not sure, that it is the most useful behavior in regards of error reporting. As said above, in my opinion pegjs does a better job in providing meaningful error messages. I am certain, that this could be improved for pigeon as well (see also the linked paper). The possible improvements would be based on some sort of heuristic within pigeon, which tries in those situations to provide the most probable error position. As stated in the above mentioned paper, in most cases, the real error position is close to the farthest position, until which the parsing was successful (before the backtracking started).I hope this helps to clarify.