GzipReader offers both a read and to_io method. The read method returns
the uncompressed file as a string. The to_io method returns the
compressed file. The JSON.load method first tests for the to_io method
and uses it before testing for the read method. This results in reading
the compressed file, which is invalid JSON.
Instead, we now test for the read method first.
https://github.com/ruby/json/commit/b6a5d35245
JSON::State.default_sort_keys_proc is registered at extension load time
so it's owned by the main Ractor.
When we implement the registration table on each Ractor storing another
Ractor's unshareable Proc into that slot leaves a dangling reference
when the owning Ractor runs a local GC.
This commit ensures that we won't use a shareable proc by raising a
Ractor::IsolationError.
json 3.0 changed `JSON.parse` to take keyword arguments instead of a
positional opts Hash, so some of the documented usage would now raise
`ArgumentError`. I have updated all such examples to use kwargs instead.
Also align documented output with what is actually produced with the
current parser/generator on Ruby 4.0, plus a number of other minor
changes.
https://github.com/ruby/json/commit/8bdd5179df
Since https://github.com/ruby/json/commit/ebf0f29, `load_file` and `load_file!` forward their arguments to
`parse` and `parse!` with `...` after a leading parameter. Ruby 2.7 accepts `...` only on its own;
a leading parameter before it was added in Ruby 3.0 and reached the 2.7 series in 2.7.3, so on Ruby 2.7.0
through 2.7.2 requiring json 3.0 raises a `SyntaxError` at `lib/json/common.rb`, while the gemspec still allows
Ruby 2.7 as a whole.
`parse` and `parse!` take keyword arguments only, so forwarding `**options` passes exactly what `...` passed,
on every Ruby the gem supports.
A `method_missing` helper in the parser tests used the same form; it takes an anonymous splat now,
so the test suite itself loads on those versions.
Checked with `ruby -c` on Ruby 2.7.0, 2.7.2, 2.7.3, and 3.0.7, and with the test suite on Ruby 2.7.2 and 3.0.7.
https://github.com/ruby/json/commit/29dad14674
I really wanted to get rid of this because the argument parsing is
awful and costly.
But `rdoc` has been using this positional argument for decades,
and while the fix has been merged, having to upgrade to the latest
rdoc is a bit too disruptive.
https://github.com/ruby/json/commit/566bd7c108
There was no single API answering "does the stream end in the middle of
a document?" once all parseable fed bytes have been consumed. Callers
had to combine two complementary APIs:
!parser.rest.empty? || !parser.partial_value.nil?
`rest` only reflects unconsumed tokenizer bytes, so it is empty when the
stream is truncated exactly on a token boundary (right after a ':' or
','), while `partial_value` is nil when truncation happens mid-token
before any container is registered. Neither alone covers all shapes,
and `partial_value` materializes the partially built Ruby objects just
to test for nil.
`partial_value?` answers the same question as `!partial_value.nil?` by
looking at the parser's internal value stack directly, without building
the partial Ruby object graph.
`empty?` is strict: true only when the buffer is fully consumed, no
document is under construction and no parsed value awaits retrieval
with `value`. It is defined in Ruby as the composition of the three
underlying predicates so its definition doubles as documentation:
def empty?
eos? && !partial_value? && !value?
end
https://github.com/ruby/json/commit/0864e83701
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sebastian Turner