fix: avoid quadratic re-scan of comments after a value (open-source-p…

…arsers#1689)

* fix: avoid quadratic re-scan of comments after a value

OurReader::readComment() decides whether a comment should be attached to
the previous value (commentAfterOnSameLine) by scanning the input from the
end of that value up to the comment with containsNewLine(). lastValueEnd_
only advances when a new value is read, so a long run of comments after a
value (e.g. during error recovery, or a value followed by many comments)
made every comment re-scan the same growing prefix, giving O(n^2) parse
time. A jsoncpp_fuzzer testcase took ~18s for a 400KB input.

A comment can only ever be on the same line as the last value if no
newline separates them, and the gap to inspect only grows as further
comments are consumed, so once the gap has been examined for the first
comment it never needs to be examined again. Mark lastValueHasAComment_
after the first comment following a value so subsequent comments skip the
scan. Parsing the testcase drops from ~18s to ~56ms with identical output.

Add a regression test that parses a value followed by a large number of
trailing comments and requires it to complete well under a generous time
bound.

* test: assert linear comment scanning deterministically

Replace the wall-clock bound in the comment regression test with a
direct, deterministic assertion on work done. The parse output is
identical with and without the fix, so the only observable difference is
how much the parser scans; a time bound is also flaky under
valgrind/sanitizers/loaded CI.

Add an instrumentation counter for the bytes examined by
OurReader::containsNewLine, exposed via a JSON_API seam, and assert it
stays linear in the input (scanned < 4 * doc.size()) rather than
O(comments * gap). The counter is thread_local (no race during
concurrent parsing) and the increment is negligible, running only while
parsing comments. It is compiled unconditionally because the ABI
compatibility job builds the test suite against a separately-installed
Release library, so the symbol must exist there. Rename the test to
parseCommentsAfterValueScansLinearly to describe what it checks, and
link crbug.com/521541633.

Verified: the test fails when the fix is reverted and passes with it, in
Debug and Release, and the seam links against a Release-installed shared
library (the ABI compatibility scenario).

---------

Co-authored-by: Jordan Bayles <[email protected]>

fix: avoid quadratic re-scan of comments after a value (open-source-p…

…arsers#1689)

* fix: avoid quadratic re-scan of comments after a value

OurReader::readComment() decides whether a comment should be attached to
the previous value (commentAfterOnSameLine) by scanning the input from the
end of that value up to the comment with containsNewLine(). lastValueEnd_
only advances when a new value is read, so a long run of comments after a
value (e.g. during error recovery, or a value followed by many comments)
made every comment re-scan the same growing prefix, giving O(n^2) parse
time. A jsoncpp_fuzzer testcase took ~18s for a 400KB input.

A comment can only ever be on the same line as the last value if no
newline separates them, and the gap to inspect only grows as further
comments are consumed, so once the gap has been examined for the first
comment it never needs to be examined again. Mark lastValueHasAComment_
after the first comment following a value so subsequent comments skip the
scan. Parsing the testcase drops from ~18s to ~56ms with identical output.

Add a regression test that parses a value followed by a large number of
trailing comments and requires it to complete well under a generous time
bound.

* test: assert linear comment scanning deterministically

Replace the wall-clock bound in the comment regression test with a
direct, deterministic assertion on work done. The parse output is
identical with and without the fix, so the only observable difference is
how much the parser scans; a time bound is also flaky under
valgrind/sanitizers/loaded CI.

Add an instrumentation counter for the bytes examined by
OurReader::containsNewLine, exposed via a JSON_API seam, and assert it
stays linear in the input (scanned < 4 * doc.size()) rather than
O(comments * gap). The counter is thread_local (no race during
concurrent parsing) and the increment is negligible, running only while
parsing comments. It is compiled unconditionally because the ABI
compatibility job builds the test suite against a separately-installed
Release library, so the symbol must exist there. Rename the test to
parseCommentsAfterValueScansLinearly to describe what it checks, and
link crbug.com/521541633.

Verified: the test fails when the fix is reverted and passes with it, in
Debug and Release, and the seam links against a Release-installed shared
library (the ABI compatibility scenario).

---------

Co-authored-by: Jordan Bayles <[email protected]>

Update bazel config for 9.x (open-source-parsers#1655)

* Update bazel config for 9.x

Bazel 9.x+ requires explicit load statements for things that were
previously included in bazel. I automatically added these with
`buildifier` and added some reasonable minimum versions to the
MODULE.bazel file.

* Fix tests for Bazel 9.x sandbox

---------

Co-authored-by: Jordan Bayles <[email protected]>
Co-authored-by: Jordan Bayles <[email protected]>

Don't use build dir build interfaces (open-source-parsers#1419)

Do not export a location in the build directory as a build interface.
This location is not created until the build step is run and can
interfere with the CMake configuration step if including in another
project.

Co-authored-by: Jordan Bayles <[email protected]>

Merge pull request open-source-parsers#1351 from open-source-parsers/…

…drop-deprecation-warnings

Drop compile-time deprecation warning

Roll version numbers for 1.9.4 release (open-source-parsers#1223)

Fixes Oss-Fuzz issue: 21916 (open-source-parsers#1180)

* Fix heap-buffer-overflow in json_reader

update README

some test coverage for Value::iterator (open-source-parsers#1093)

\open-source-parsers#979 Fix parseFromStream definition

This patch fixes issue open-source-parsers#979, where the parseFromStream definition in
the header is different from the implementation.