Merge of the following upstream commits:
commit 6d3266dc0edbbdb1dae513f4f3be16198c432af3
Author: Jean Boussier <byroot@ruby-lang.org>
Date: Mon Nov 2 15:51:58 2026 +0100
Release 2.18.2
commit dcfbbcd36f240c18c3b89e5399105715f70162e3
Author: Jean Boussier <jean.boussier@gmail.com>
Date: Wed Mar 25 11:45:17 2026 +0100
Fix handling of unescaped control characters preceeded by a backslash
GHSA-cjpr-jw2g-fw99
commit 6ec6e7baff137e67831a23090061e84bf028dbfc
Author: Jean Boussier <jean.boussier@gmail.com>
Date: Tue Feb 3 08:35:11 2026 +0100
Release 2.18.1
commit fff25c9f4b9c590a59ed4a2ec3c545121db844d3
Author: Jean Boussier <jean.boussier@gmail.com>
Date: Mon Feb 2 19:44:02 2026 +0100
fbuffer_append_str: assume string
commit 79b6e168ba02f6ac7a0dac378968b1c918af91db
Author: Jean Boussier <jean.boussier@gmail.com>
Date: Mon Feb 2 22:06:44 2026 +0100
Ensure `Generator::State` is kept on the stack
Fix: https://github.com/ruby/json/issues/929
When calling `cState_partial_generate` from `mHash_to_json` or other
`to_json` funcs, `VState` becomes unreachable very quickly, hence the
compiler may optimize it out of the stack, and make it invisible to
the GC stack scanning. This is particularly liekly given how aggressively
we inline.
Repro:
```ruby
require 'json'
test_data = {
"flag" => true,
"data" => 10000.times.map { [1.0] },
:flag => false,
}
10.times do
test_data.to_json
end
```
But in practice the cause was just that the issued warning calls
Hash#inspect on a big hash, which triggers GC.
So it can be triggered even more reliably with:
```ruby
require 'json'
module JSON
module Common
def self.on_mixed_keys_hash(...)
GC.start
end
end
end
test_data = {
"flag" => true,
"data" => 10000.times.map { [1.0] },
:flag => false,
}
test_data.to_json
```
commit 062fcdd22818d226f0e4b49647eb2aabbfaf002b
Author: BurdetteLamar <burdettelamar@yahoo.com>
Date: Thu Jan 22 22:08:15 2026 +0000
Improve class JSON intro
commit 1b276c8623da0ff9bec62396d9a7172365bc1784
Author: Jean Boussier <jean.boussier@gmail.com>
Date: Fri Jan 16 18:43:08 2026 +0100
Extract json_fast_memcpy16 for readability
commit 643ee11fed6898b7e6f75f266daa6e4b2a07bb07
Author: Scott Myron <samyron@gmail.com>
Date: Thu Jan 15 19:12:41 2026 -0600
Use __builtin_memcpy, if available, to copy overlapping byte ranges in copy_remaining_bytes to avoid a branch to MEMCPY. Additionally use a space as padding byte instead of an 'X' so it can be represented diretly on AArch64 with a single instruction.
commit 15eb40dbdfb299813bbbb72f70e12d1614b26200
Author: Nobuyoshi Nakada <nobu@ruby-lang.org>
Date: Wed Jan 14 21:28:37 2026 +0900
Remove trailing spaces [ci skip]
commit 73818b80c8fe4394153002a60ecd285e8688b4cd
Author: Scott Myron <samyron@gmail.com>
Date: Tue Jan 13 22:17:16 2026 -0600
initialize search.chunk_end to silence a warning about it being potentially uninitialized
commit 86a5cce405102eca15d639e2dae2f539fb3e7c26
Author: Scott Myron <samyron@gmail.com>
Date: Mon Jan 12 18:57:09 2026 -0600
use a conditional to select SIMD implementation rather than pointer
commit a51317c94900ec5ea44ef0fd9327cca4d601bb5c
Author: Scott Myron <samyron@gmail.com>
Date: Fri Jan 2 20:47:59 2026 -0600
Directly write to the output buffer when converting UTF32 to UTF8.
commit 3e23e57568d29aa96f73d5f0c27b8c3676af4ee5
Merge: 976ba366 8ad744c5
Author: Nobuyoshi Nakada <nobu@ruby-lang.org>
Date: Wed Dec 31 21:43:48 2025 +0900
Merge pull request #921 from nobu/nonportable-code
Fix non-portable code
commit 8ad744c53269330cc827bf4ae213991ae11712ce
Author: Nobuyoshi Nakada <nobu@ruby-lang.org>
Date: Wed Dec 31 21:40:16 2025 +0900
Fix non-portable code
A plain `char` may be `signed` or `unsigned` depending on the
implementation. Also, bitwise ORing of `signed` values is not
guaranteed to be `signed`. To ensure portability, should logical-OR
each comparison, but casting to `signed char` is usually sufficient.
commit 976ba36629b2d20fa4de3da12ed405ab178deeba
Author: Scott Myron <samyron@gmail.com>
Date: Tue Dec 30 21:32:03 2025 -0600
Simplify unescape_unicode
Co-Authored-By: Jean Boussier <jean.boussier@gmail.com>
commit d21d9362fa36bd1b34c53e28b04ba6e91115a3be
Author: Scott Myron <samyron@gmail.com>
Date: Tue Dec 30 20:48:18 2025 -0600
Keep track of the the number of additional backslashes to avoid an extra memchr searching the remaining characters when no more backslashes exist.
commit a5c160f37285cab4406017990a6a02e82e283055
Author: Jean Boussier <jean.boussier@gmail.com>
Date: Mon Dec 22 09:16:09 2025 +0100
Add missing documentation for `allow_control_characters` parsing option
commit 4808fee9affb801bc9bc63ea2d69d1cb28deda2a
Author: 久我山菜々 <nna@nna774.net>
Date: Fri Dec 19 01:30:37 2025 +0900
Update `fpconv_dtoa` definition to use `dest[32]`
commit 5793694ee6632245f345e3b923af5ebfd7db68a9
Author: Étienne Barrié <etienne.barrie@gmail.com>
Date: Thu Dec 11 16:12:35 2025 +0100
Revert "Skip test failing with JRuby in CI"
This reverts commit b7e1734d9ca090e95b1923b05536f5fb6f437060.
While it's not allowed by the spec, some parsers like Oj do
accept it, and it can be blocking a transition.
Having this feature can help people migrate.
https://github.com/ruby/json/commit/3459499cb3
The caller already know if the string contains escape sequences
so this check is redundant.
Also stop calling `rstring_cache_fetch` from `json_string_unescape`
as we know it won't match anyways.
```
== Parsing twitter.json (567916 bytes)
ruby 3.4.6 (2025-09-16 revision https://github.com/ruby/json/commit/dbd83256b1) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
after 122.000 i/100ms
Calculating -------------------------------------
after 1.226k (± 0.3%) i/s (815.85 μs/i) - 6.222k in 5.076282s
Comparison:
before: 1206.2 i/s
after: 1225.7 i/s - 1.02x faster
```
https://github.com/ruby/json/commit/b8cdf3282d
Co-Authored-By: Scott Myron <samyron@gmail.com>
Because both strings and symbols keys are serialized the same,
it always has been possible to generate documents with duplicated
keys:
```ruby
>> puts JSON.generate({ foo: 1, "foo" => 2 })
{"foo":1,"foo":2}
```
This is pretty much always a mistake and can cause various
issues because it's not guaranteed how various JSON parsers
will handle this.
Until now I didn't think it was possible to catch such case without
tanking performance, hence why I only made the parser more strict.
But I finally found a way to check for duplicated keys cheaply enough.
