When running tests that involve 2 runs of the parser, one with the
`StrInput` and another with the `BufferedInput`, the output of debug
prints can be confusing as it's unclear where one parser ends parsing
and the other starts. These 2 prints allow us to know when each is
started and, if one errors but not the other, to know which did.
This requires making the `input` mod public, as some items in
`char_traits` are referenced in `Input`'s function doccomments.
The items have been exposed in `input` directly, rather than in a
`saphyr::input::char_traits` submod.
This issue arises in the `yaml-test-suite` not in a test, but rather in
the test description files themselves. Since we now use the library
itself to load the test files, this made the `yaml-test-suite` fail.
Look ahead before testing for EOF.
This fixes panics in saphyr's test_multiline_trailing_newline and
test_multiline_leading_newline tests, in which `self.input.next_is_z`
would be called on an empty buffer and panic in `peek`
Previously, we often used the scanner state to infer the positions of
mappings. This is sometimes wrong, because the scanner has already
scanned ahead by the time the mapping is parsed.
This commit adds a check to the test suite, asserting that parser event
positions are all observed in order, and it fixes the scanner and parser
to make the new check pass.
We reserve bufmaxlen bytes in the string, but then proceed to push
up to bufmaxlen chars. Therefore it is possible that the string will
need to reallocate. A different solution would be to reserve
4*bufmaxlen bytes. Removing the assert is probably ok, because the
attempt to pre-allocate is just a performance optimization.
