| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/ruby/json/commit/15eb40dbdf
|
|
potentially uninitialized
https://github.com/ruby/json/commit/73818b80c8
|
|
https://github.com/ruby/json/commit/86a5cce405
|
|
https://github.com/ruby/json/commit/ccca602274
|
|
When serializing an Array, and one of the elements of the Array requires
calling `to_json`, if the depth is changed, it will be used for the next
entries, which wasn't the case before
https://github.com/ruby/json/commit/5abd43490714, and is not the case with
TruffleRuby and JRuby.
Additionally, with TruffleRuby and JRuby the state's depth after the
`to_json` call is used to close the Array, which isn't the case with
CRuby.
https://github.com/ruby/json/commit/386b36fde5
|
|
`ALWAYS_INLINE()` and `NOINLINE()` are defined with one argument.
https://github.com/ruby/json/commit/8fb727901e
|
|
https://github.com/ruby/json/commit/9c36681b17
|
|
Now that the state isn't mutated in generate_new, we no longer need to
copy the struct, we can just use it.
https://github.com/ruby/json/commit/d7964f8892
|
|
For `JSON.generate` and `JSON::State#generate_new`, don't copy
generate_json_data::depth to JSON_Generator_State::depth.
In `JSON.generate`, the JSON_Generator_State is on the stack and
discarded anyway. In `JSON::State#generate_new`, we copy the struct to
avoid mutating the original one.
https://github.com/ruby/json/commit/873b29ea34
|
|
Instead of incrementing JSON_Generator_State::depth, we now increment
generate_json_data::depth, and only copied at the end.
https://github.com/ruby/json/commit/5abd434907
|
|
https://github.com/ruby/json/commit/2a4ebe8250
|
|
https://github.com/ruby/json/commit/58d60d6b76
|
|
https://github.com/ruby/json/commit/9364d0c761
|
|
debugging code is not generated when JSON_DEBUG=0.
https://github.com/ruby/json/commit/4f1adb10d3
|
|
Followup: https://github.com/ruby/json/pull/889
https://github.com/ruby/json/commit/591510392a
|
|
|
|
https://github.com/ruby/json/commit/1576ea7d47
|
|
Fix: https://github.com/ruby/json/issues/873
This allow users to encode binary strings if they so wish.
e.g. they can use Base64 or similar, or chose to replace invalid
characters with something else.
https://github.com/ruby/json/commit/b1b16c416f
|
|
part 2
Commit https://github.com/ruby/json/commit/44df509dc2de fixed it for StandardError, but other exceptions and
jumps are also possible. Use rb_ensure() to release FBuffer instead of
rb_rescue().
A reproducer:
o = Object.new
def o.to_json(a) = throw :a
a = ["make heap allocation"*100, o]
10.times do
100_000.times do
catch(:a) { JSON(a) }
end
puts `ps -o rss= -p #{$$}`
end
https://github.com/ruby/json/commit/9b7b648ecd
|
|
https://github.com/ruby/json/commit/965ba6c5d4
|
|
Fix: https://github.com/rails/rails/commit/90616277e3d8fc46c9cf35d6a7470ff1ea0092f7#r168784389
Because the `depth` counter is inside `JSON::State` it can't be used
concurrently, and in case of a circular reference the counter may be
left at the max value.
The depth counter should be moved outside `JSON_Generator_State` and
into `struct generate_json_data`, but it's a larger refactor.
In the meantime, `JSON::Coder` calls `State#generate_new` so I changed
that method so that it first copy the state on the stack.
https://github.com/ruby/json/commit/aefa671eca
|
|
e.g.
```ruby
{ 1 => 2 }
```
The callback will be invoked for `1` as while it has a native JSON
equivalent, it's not legal as an object name.
|
|
Fix: https://github.com/ruby/json/issues/861
It's not incorrect to use scientific notation, but it tend
to throw people off a bit, so it's best to keep it for very large
numbers.
https://github.com/ruby/json/commit/1566cd01a6
|
|
Fix: https://github.com/ruby/json/pull/843
https://github.com/ruby/json/commit/d3f7f0452b
Co-Authored-By: Takashi Kokubun <takashikkbn@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.
|
|
|
|
|
|
https://github.com/ruby/json/commit/12656777dc
|
|
|
|
All the `json/add` related methods for string were
always defined unconditionally from the generators.
It's preferable to only define them if `json/add` is actually used.
|
|
Found by wbcheck
WBCHECK ERROR: Missed write barrier detected!
Parent object: 0x7b7b8487c450 (wb_protected: true)
rb_obj_info_dump: 0x00007b7b8487c450 JSON/Generator/State/JSON::Ext::Generator::State JSON/Generator/State
Reference counts - snapshot: 1, writebarrier: 0, current: 6, missed: 5
Missing reference to: 0x7b7b82f35a10
rb_obj_info_dump: 0x00007b7b82f35a10 T_STRING/String len: 1, capa: 15 "1"
Missing reference to: 0x7b7b82f35e90
rb_obj_info_dump: 0x00007b7b82f35e90 T_STRING/String len: 1, capa: 15 "2"
Missing reference to: 0x7b7b83629e50
rb_obj_info_dump: 0x00007b7b83629e50 T_STRING/String len: 1, capa: 15 "3"
Missing reference to: 0x7b7b83b62190
rb_obj_info_dump: 0x00007b7b83b62190 T_STRING/String len: 1, capa: 15 "4"
Missing reference to: 0x7b7b83629490
rb_obj_info_dump: 0x00007b7b83629490 T_STRING/String len: 1, capa: 15 "5"
https://github.com/ruby/json/commit/c24342d801
|
|
|
|
https://github.com/ruby/json/commit/a497c71960
|
|
When both extconf.rb of generator and parser are run in one process,
the second `require_relative` does nothing.
https://github.com/ruby/json/commit/8e775320b7
|
|
|
|
https://github.com/ruby/json/commit/3ae3eeb9d3
|
|
|
|
https://github.com/ruby/json/commit/6c41162522
|
|
https://github.com/ruby/json/commit/a29cb77d52
|
|
This would have caught https://github.com/ruby/json/pull/808
on CI.
https://github.com/ruby/json/commit/8109421fb4
|
|
negative floats.
Fix: https://github.com/ruby/json/issues/807
Since https://github.com/ruby/json/pull/800, `fpconv_dtoa` can actually
generate up to 28 chars.
https://github.com/ruby/json/commit/d73ae93d3c
|
|
Fix: https://github.com/ruby/json/issues/796
Notes:
Merged: https://github.com/ruby/ruby/pull/13227
|
|
https://github.com/ruby/json/commit/6b059900de
.
|
|
https://github.com/ruby/json/commit/d7d60cccb0
|
|
We should test compilation with `-msse2` because we need to
test with whatever arguments Ruby will be compiled with.
https://github.com/ruby/json/commit/0a871365db
|
|
`c < 32 || c == 34` is equivalent to `c ^ 2 < 33`.
Found in: https://lemire.me/blog/2025/04/13/detect-control-characters-quotes-and-backslashes-efficiently-using-swar/
The gain seem mostly present on micro-benchmark, and even there aren't
very consistent, but it's never slower.
```
== Encoding long string (124001 bytes)
ruby 3.4.2 (2025-02-15 revision https://github.com/ruby/json/commit/d2930f8e7a) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
after 5.295k i/100ms
Calculating -------------------------------------
after 55.796k (± 3.4%) i/s (17.92 μs/i) - 280.635k in 5.035690s
Comparison:
before: 49840.7 i/s
after: 55795.8 i/s - 1.12x faster
```
https://github.com/ruby/json/commit/034c5debd8
|
|
|
|
(https://github.com/ruby/json/pull/743)
See the pull request for the long development history: https://github.com/ruby/json/pull/743
```
== Encoding activitypub.json (52595 bytes)
ruby 3.4.2 (2025-02-15 revision https://github.com/ruby/json/commit/d2930f8e7a) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
after 2.913k i/100ms
Calculating -------------------------------------
after 29.377k (± 2.0%) i/s (34.04 μs/i) - 148.563k in 5.059169s
Comparison:
before: 23314.1 i/s
after: 29377.3 i/s - 1.26x faster
== Encoding citm_catalog.json (500298 bytes)
ruby 3.4.2 (2025-02-15 revision https://github.com/ruby/json/commit/d2930f8e7a) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
after 152.000 i/100ms
Calculating -------------------------------------
after 1.569k (± 0.8%) i/s (637.49 μs/i) - 7.904k in 5.039001s
Comparison:
before: 1485.6 i/s
after: 1568.7 i/s - 1.06x faster
== Encoding twitter.json (466906 bytes)
ruby 3.4.2 (2025-02-15 revision https://github.com/ruby/json/commit/d2930f8e7a) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
after 309.000 i/100ms
Calculating -------------------------------------
after 3.115k (± 3.1%) i/s (321.01 μs/i) - 15.759k in 5.063776s
Comparison:
before: 2508.3 i/s
after: 3115.2 i/s - 1.24x faster
```
https://github.com/ruby/json/commit/49003523da
|
|
https://github.com/ruby/json/commit/b14250f1da
|
|
We can't directly call `RBASIC_CLASS` as the return value of
`to_s` may be an immediate.
https://github.com/ruby/json/commit/12dc394d11
|
