Open MinusGix opened 11 months ago
Thanks for your report!
I am not sure of the best path forward here since it seems to be an ambiguous failure condition.
In your test case, it seems like EOF condition should be considered for any variant instead of all variants, but then this would be more likely to mask parser bugs in other cases. For example, it could be the case that Thing1
fails due to an error in the middle of parsing, then Thing0
does not have any magic or precondition because it is some fallback, tries to parse, and fails with EOF because it is the wrong variant entirely. In this case you would want the error of Thing1
to be reported but instead it would be silently treated as a successful EOF.
So it seems like there are a few different potential conditions someone might want for a successful EOF and to resolve this it might be necessary to expose a control for the author to decide what they want:
The third option I think would require adding new error variant to discriminate between a pre-assert variant failure and an assertion failure somewhere else (which is fine).
Example:
And I just made a 16byte file to test it with.
(Side question: is there a better way to pass args to the inner part with until eof?)
This results in a panic.
I think the issue is that
is_eof
looks intoEnumErrors
but doesn't test if the first is a pre-assert and the second a backtrace with an eof? I don't know if there's a more general proper way.I reimplemented
is_eof
locally with the manual check for EnumAssert with [Assert, Backtrace that has an eof error]