Closed JC-LL closed 10 years ago
Thanks for opening this issue. It should be resolved now with the release of the 1.5.3 version of the gem. This release also contains 1.5.2, which added regexps and was never separately released. the current github version is 1.6.0 which contains significant new error reporting behaviours, but the changes are big enough that I won't release it as a gem for a few weeks. You're welcome to clone the repo and "rake install" the 1.6.0 version and to provide feedback.
Hello
At least I tried 1.6.0 from github and it worked fine !
Thx ! JCLL
2014-03-21 12:48 GMT+01:00 Clifford Heath notifications@github.com:
Thanks for opening this issue. It should be resolved now with the release of the 1.5.3 version of the gem. This release also contains 1.5.2, which added regexps and was never separately released. the current github version is 1.6.0 which contains significant new error reporting behaviours, but the changes are big enough that I won't release it as a gem for a few weeks. You're welcome to clone the repo and "rake install" the 1.6.0 version and to provide feedback.
Reply to this email directly or view it on GitHubhttps://github.com/cjheath/treetop/issues/10#issuecomment-38268984 .
Hello,
I'd like to understand error reporting in Treetop generated parsers. Given a simple grammar like this :
And a test file simply containing an erroneous program (space and ident missing) : (entity)
...I'd expect Treetop to provide a message mentioning the absence of space and ident.
But it only returns : Parse error at offset: 0 (RuntimeError)
Maybe there is a way to overcome this, in my code, and get something more meaningfull ?
Thx in advance JCLL/Natelljahns
Answer by Clifford The problem is that Treetop doesn’t create any TerminalParseFailure for a failed character class, as it does for literal strings. The failure_reason reports on the TerminalParseFailures at the rightmost position that was successfully matched.
I think the fix is pretty simple, but I’m not certain it won't affect the behaviour of the parser, so I need to check that carefully before applying it. It will certainly incur a slight performance cost, but probably not too much.