Follow-up to #1557 / #1615, as discussed in #1615 (comment) (with @cowtowncoder agreeing async warrants a separate change).
Background
#1615 generalized the root-only _verifyRootSpace into _verifyNumberSeparator and now eagerly validates the separator after non-root number values, but only in the three blocking parsers (ReaderBasedJsonParser, UTF8StreamJsonParser, UTF8DataInputJsonParser).
The non-blocking / async parser path (NonBlockingJsonParserBase and its subclasses NonBlockingJsonParser / NonBlockingByteArrayJsonParser) was intentionally left out of that PR and still fails lazily — the malformed content is only detected when the next token is read, one token too late.
Repro
The same inputs from #1557 that are now caught eagerly by the blocking parsers still slip through on the async path:
[ 123true ] // -> reports number token 123, fails only on next token
[ 100k ] // -> 100
[ 100/ ] // -> 100
[ 1.5x ] // -> 1.5
[ 1.5false ] // -> 1.5
Scope
Apply the equivalent trailing-separator check at the number-completion sites in the non-blocking parser so async parsing reports the error at the offending character, matching the blocking parsers' behavior and location. Async introduces NEED_MORE_INPUT boundaries at end-of-chunk, so the check has to tolerate a not-yet-available trailing byte (defer the decision to the next feed rather than reject), which is why this is a separate change from #1615.
Happy to pick this up.
Follow-up to #1557 / #1615, as discussed in #1615 (comment) (with @cowtowncoder agreeing async warrants a separate change).
Background
#1615 generalized the root-only
_verifyRootSpaceinto_verifyNumberSeparatorand now eagerly validates the separator after non-root number values, but only in the three blocking parsers (ReaderBasedJsonParser,UTF8StreamJsonParser,UTF8DataInputJsonParser).The non-blocking / async parser path (
NonBlockingJsonParserBaseand its subclassesNonBlockingJsonParser/NonBlockingByteArrayJsonParser) was intentionally left out of that PR and still fails lazily — the malformed content is only detected when the next token is read, one token too late.Repro
The same inputs from #1557 that are now caught eagerly by the blocking parsers still slip through on the async path:
Scope
Apply the equivalent trailing-separator check at the number-completion sites in the non-blocking parser so async parsing reports the error at the offending character, matching the blocking parsers' behavior and location. Async introduces
NEED_MORE_INPUTboundaries at end-of-chunk, so the check has to tolerate a not-yet-available trailing byte (defer the decision to the next feed rather than reject), which is why this is a separate change from #1615.Happy to pick this up.