-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Predicates shouldn't be wrapped in SILENT_FAILS #455
base: main
Are you sure you want to change the base?
Conversation
The problem is not so simple and reporting expected from predicates can create many false-positives. This need to be carefully checked. In your examples the symbol is checked on the first position, but them actually can be deeper. Even in the test that you changed the new behaviour do report actually impossible input: start = 'a' / &'b' / 'c' That grammar does not accept Expectations from predicates are difficult and from negative predicates are especially difficult. Probably the current behavior the best balance between accurate and complete reporting. |
That's true, but you don't take account of what might happen later in the grammar anywhere else. eg
Peggy reports '[a-c]' expected, even though the grammar doesn't match anything, in much the same way. So I think it makes sense to report that
Now saying that it expects 'a' or 'c' is definitely wrong - it really does accept 'a', 'b', or 'c'. Its probably just a failure of imagination on my part, but I can't think of a case where its wrong to include the predicate failure... can you provide examples? [edit: I guess in the negative cases, its going to be wrong because it will report that it was expecting something, when in fact it was expecting anything but something - so I can see that that part of the pull request is wrong. Not sure yet if its fixable] |
It still makes sense to report expectations in this case, since the first character really has to be start = 'a' / 'b' 'c' This grammar accepts only
At least it does not say anything that wouldn't be true. Some valid inputs are missed in the message, but the message never contains invalid inputs. I think, that this property is more important. Believe, I tried to implement better error handling taking expectations from predicates and even created negative expectations, but I remember that in real cases that does not look well. Although I never tried to work only with positive predicates. |
I'm still having a hard time understanding your argument here.
Which is also the case for
No, it will be reported whether or not there's a second character. You seem to be arguing that because the grammar might be self contradictory, we shouldn't report the
You still haven't provided an example where reporting (positive) matches would do that though... |
As noted above, its definitely not right for negative predicates. |
If a predicate fails, its failure needs to be recorded:
Before:
Note the first one doesn't have a failure explanation at all, and the second says that 'c' was expected, when 'b' or 'c' would have been acceptable.
After:
There were tests for the second case, but they were testing the actual behavior, rather than what (I think) it should be doing.