Add failing tests for #1173: off-by-one discrepancy in the location of reported parser errors #1175
Conversation
|
Curiously, |
| 26, | ||
| 24, | ||
| 1, | ||
| 25 |
There was a problem hiding this comment.
Parser backends aren't consistent about the column in this case, because the exact definition of "column" seems to depend on whether the parser is operating on a byte array or a character array. I'm open to suggestions about what to do with this case.
There was a problem hiding this comment.
Column should be exactly same for byte/char -backed input, for ASCII characters (for multi-byte characters there is indeed difference). But I think few tests use characters outside ASCII range..
|
|
||
| byte[] inputBytes = input.getBytes(StandardCharsets.UTF_8); | ||
| feeder.feedInput(inputBytes, 0, inputBytes.length); | ||
| feeder.endOfInput(); |
There was a problem hiding this comment.
I don't think this works the way you'd expect... I think endOfInput() should not be called until all input is consumed.
There was a problem hiding this comment.
Or maybe I misremember this part, as test appears to work fine :)
This adds (currently failing) test cases for the issue identified in #1173. I've tried my best at adding a plethora of different variations of invalid JSON, but it's possible I might still be missing some edge cases. I also have written this to test every variation of invalid JSON against the four parser backends identified by @cowtowncoder in the issue comments.