Neither the `__builtin_cpu_supports` probe in conf.rb nor `cpuid.h` has a use now that SSE2 is assumed on x86-64. The probe kept SIMD off on GCC older than 4.8, and the `HAVE_CPUID_H` guard broke builds that have `x86intrin.h` but not `cpuid.h` with a redefinition of `find_simd_implementation`.
https://github.com/ruby/json/commit/fae76b9eb4
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
__builtin_cpu_supports refers to __cpu_model in compiler-rt, which clang-cl does not link, so generator.so and parser.so failed with an undefined symbol. SSE2 is part of the x86-64 baseline, as NEON is for AArch64, where no check is made either.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`spe` is the string end, so if the escape is incomplete, it doesn't
mean we reached the end of stream, hence it's a syntax error, not
an EOS error.
https://github.com/ruby/json/commit/c1a4372837
The column of a parse error is a character position in the source, so it follows them while the line number stays long. It falls back to long on Ruby versions that do not define HAVE_RB_LEN_T.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Convert non-Proc on_load callbacks through to_proc and validate the result in the shared parser configuration. Previously, arbitrary values were stored and passed directly to rb_proc_call_with_block.
Cover Method callbacks in JSON.parse, JSON::Coder, and ResumableParser, along with invalid types, invalid conversion results, and nil or false callbacks.
https://github.com/ruby/json/commit/672da19fd5
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
Convert non-Proc callbacks through to_proc and validate the result in both configuration and the as_json setter. rb_convert_type accepts unrelated T_DATA objects without conversion, allowing them to reach Proc APIs and crash.
Cover Method callbacks, invalid callback types, and to_proc returning a non-Proc object.
https://github.com/ruby/json/commit/f5c889de9c
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
The C parser guards leading-first surrogate pairs but silently accepts
a lone trailing surrogate, encoding U+DC00..U+DFFF as three UTF-8 bytes
into the output buffer. The returned Ruby String is tagged UTF-8 but
fails valid_encoding? and raises misleading errors from downstream
String operations (upcase, split, regex, encode, JSON.generate).
Add a symmetric branch alongside the leading-surrogate check to raise
JSON::ParserError at the parse boundary. Extend test_invalid_surogates
with the new cases and move the three JSONTestSuite fixtures that this
fix newly rejects from INVALID_ENCODING_TESTS into UNDEFINED_FAILING,
closing the CRuby/JRuby parser parity gap documented in the file.
https://github.com/ruby/json/commit/82bf6bedcf
In strict mode, a Symbol whose name is not UTF-8 compatible was passed to
generate_json_string, which handed the as_json result to
raw_generate_json_string without checking its type. A non-String result was
then read as a String, segfaulting the process.
Route strict symbols through the T_STRING case of generate_json_general so
they reuse its as_json handling. That re-dispatches the result by type, and
its as_json_called flag stops a symbol returned by as_json from recursing.
https://github.com/ruby/json/commit/2d73e6bdfe
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sebastian Turner