June 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:125841] [Ruby Bug#22131] Avoid array allocation in `Array#include?` on literal arrays
by Strech (Sergey Fedorov) 26 Jun '26

26 Jun '26

Issue #22131 has been reported by Strech (Sergey Fedorov). ---------------------------------------- Bug #22131: Avoid array allocation in `Array#include?` on literal arrays https://bugs.ruby-lang.org/issues/22131 * Author: Strech (Sergey Fedorov) * Status: Open * ruby -v: ruby 4.1.0dev * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've noticed that `Array#include?` on a literal array of frozen-shareable elements (Integers, Symbols, true/false/nil, frozen String literals) compiles the receiver to `duparray`, which allocates a fresh `Array` copy on every call — even though `#include?` only reads it. **Before** ```ruby # frozen_string_literal: true [1, 2].include?(3) ``` ``` == disasm: #<ISeq:<main>@-e:2 (2,0)-(2,18)> 0000 duparray [1, 2] ( 2)[Li] 0002 putobject 3 0004 opt_send_without_block <calldata!mid:include?, argc:1, ARGS_SIMPLE> 0006 leave ``` **After** ```ruby # frozen_string_literal: true [1, 2].include?(3) ``` ``` == disasm: #<ISeq:<main>@-e:2 (2,0)-(2,18)> 0000 putobject 3 ( 2)[Li] 0002 opt_duparray_send [1, 2], :include?, 1 0006 leave ``` **Benchmarks** ```ruby require 'benchmark/ips' GC.disable ARR = [1, 2, 3] Benchmark.ips do |x| x.report "literal [1,2,3].include?(2)" do |loop| loop.times { [1, 2, 3].include?(2) } end x.report "constant ARR.include?(2)" do |loop| loop.times { ARR.include?(2) } end x.compare! end ``` | case | master | candidate | speedup | |---|---|---|---:| | `[1,2,3].include?(2)` | 17.83M i/s (56.09 ns) | 30.00M i/s (33.33 ns) | 1.68x | | `ARR.include?(2)` (const) | 23.92M i/s (41.80 ns) | 23.92M i/s (41.81 ns) | ~1.00x | Github PR: https://github.com/ruby/ruby/pull/17496 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125838] [Ruby Feature#22130] Add a new YARV instruction for a `String.new` fast path
by tenderlovemaking (Aaron Patterson) 25 Jun '26

25 Jun '26

Issue #22130 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #22130: Add a new YARV instruction for a `String.new` fast path https://bugs.ruby-lang.org/issues/22130 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- I would like to introduce a new YARV instruction, `opt_string_new`. It's similar to `opt_new`, but it is specialized for strings. Today, we [define the `new` method on `String`](https://github.com/ruby/ruby/blob/5d1a0239de4934cb38b0f7507783d43f0da4ab26/string.c#L12890). The reason we define the `new` method on `String` is because people can call `new` with a capacity like this: ```ruby s = String.new(capacity: 1234) ``` We want to pass the capacity to the GC so that we can ask the GC to possibly allocate a "right sized" object that includes the underlying string buffer. If we didn't implement `new`, then we would be forced to allocate a regular 40 byte slot _as well as_ a `malloc` buffer for the string. There are a few downsides to the current implementation. First, users can subclass `String` and expect the signature they define on `initialize` be the same signature that is expected for `new`. For example ```ruby class CoolString < String def initialize(is_cool:) @is_cool = is_cool super(encoding: "UTF-8") end end CoolString.new(is_cool: true) ``` In order to handle this, the `new` implementation on `String` [must check that the receiver is String, and if not, it forwards the call](https://github.com/ruby/ruby/blob/5d1a0239de4934cb38b0f7507783d43f0da…. The user can call `super` from `initialize`, and they expect the string to be setup in the normal fashion (setting the encoding, etc). That means that the implementation of `rb_str_s_new` is very similar to `rb_str_init` (we have a lot of duplicated code). The other down side is that since `new` can accept keyword arguments, we end up with an extra hash allocation when calling the C method. I would like to propose adding an `opt_string_new` instruction that does the "right sized allocation" and then calls `initialize` on the instance. For example, when we compile code like `String.new(capacity: 123)`, we can know where "capacity" will be stored on the stack at compile time. Since we have the capacity, we can emit an `opt_string_new` instruction that allocates the string and then delegates to `initialize` (which we'll rewrite in Ruby). To make this more concrete, here are the iseqs today: ``` ruby --dump=insns -e'String.new(capacity: 123)' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,25)> 0000 opt_getconstant_path <ic:0 String> ( 1)[Li] 0002 putnil 0003 swap 0004 putobject 123 0006 opt_new <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000086110c>], KWARG>, 13 0009 opt_send_without_block <calldata!mid:initialize, argc:1, kw:[#<Symbol:0x000000000086110c>], FCALL|KWARG> 0011 jump 16 0013 opt_send_without_block <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000086110c>], KWARG> 0015 swap 0016 pop 0017 leave ``` Here is what I'm proposing: ``` > ruby --dump=insns -e'String.new(capacity: 123)' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,25)> 0000 opt_getconstant_path <ic:0 String> ( 1)[Li] 0002 putnil 0003 swap 0004 putobject 123 0006 opt_string_new <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000085f10c>], KWARG>, 13, 0 0010 pop 0011 jump 16 0013 opt_send_without_block <calldata!mid:new, argc:1, kw:[#<Symbol:0x000000000085f10c>], KWARG> 0015 swap 0016 pop 0017 leave ``` I've made a WIP pull request here: https://github.com/ruby/ruby/pull/17482 Here are a few benchmark results comparing against Ruby's master branch. Interpreter + `String.new` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new' ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +PRISM [arm64-darwin25] String.new: 19.811M i/s (± 0.6%, GC 6.3%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +PRISM [arm64-darwin25] String.new: 44.473M i/s (± 0.9%, GC 14.4%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 2.24 ± 0.02 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` Interpreter + `String.new(capacity: 123) (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(capacity: 123)' ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +PRISM [arm64-darwin25] String.new(capacity: 123): 10.179M i/s (± 1.1%, GC 17.7%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +PRISM [arm64-darwin25] String.new(capacity: 123): 35.924M i/s (± 0.4%, GC 20.2%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 3.53 ± 0.04 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` Interpreter + `String.new(encoding: "UTF-8")` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(encoding: "UTF-8")' ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 8.282M i/s (± 2.5%, GC 12.0%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 7.770M i/s (± 1.6%, GC 2.7%) Summary ruby /Users/aaron/.rubies/arm64/master/bin/ruby ran 1.07 ± 0.03 times faster than ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ``` The first two cases easily win with this patch. Passing only an encoding may be slightly slower, but they are very close (and the allocations are decreased). Here are the same benchmarks but with YJIT enabled: YJIT + `String.new` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new' --yjit ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +YJIT +PRISM [arm64-darwin25] String.new: 31.008M i/s (± 0.8%, GC 9.8%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +YJIT +PRISM [arm64-darwin25] String.new: 97.603M i/s (± 0.8%, GC 30.9%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 3.15 ± 0.04 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` YJIT + `String.new(capacity: 123) (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(capacity: 123)' --yjit ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +YJIT +PRISM [arm64-darwin25] String.new(capacity: 123): 12.986M i/s (± 1.3%, GC 22.2%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +YJIT +PRISM [arm64-darwin25] String.new(capacity: 123): 77.827M i/s (± 0.4%, GC 42.0%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 5.99 ± 0.08 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` YJIT + `String.new(encoding: "UTF-8")` (iterations / s, higher is better): ``` ips --ruby /Users/aaron/.rubies/arm64/master/bin/ruby --ruby $(which ruby) -e 'String.new(encoding: "UTF-8")' --yjit ruby 4.1.0dev (2026-06-24T21:17:33Z master bb75c2893a) +YJIT +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 9.909M i/s (± 0.5%, GC 13.9%) ruby 4.1.0dev (2026-06-25T19:50:18Z new-in-ruby 52a8c02e69) +YJIT +PRISM [arm64-darwin25] String.new(encoding: "UTF-8"): 11.916M i/s (± 0.7%, GC 3.8%) Summary ruby /Users/aaron/.rubies/arm64/new-in-ruby/bin/ruby ran 1.20 ± 0.01 times faster than ruby /Users/aaron/.rubies/arm64/master/bin/ruby ``` The first two benchmarks are much faster than the master branch, and the last benchmark is faster because I moved `initialize` to Ruby. I've implemented this in ZJIT too, but I'm not going to post the numbers because they are very similar to YJIT for this micro benchmark. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125762] [Ruby Bug#22115] [BUG] segmentation fault
by robert12 (Robert Gleeson) 25 Jun '26

25 Jun '26

Issue #22115 has been reported by robert12 (Robert Gleeson). ---------------------------------------- Bug #22115: [BUG] segmentation fault https://bugs.ruby-lang.org/issues/22115 * Author: robert12 (Robert Gleeson) * Status: Open * ruby -v: ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello. I did not reproduce this locally. I found it on CI. I'm reporting in case it has not been fixed or reported before. CI: https://github.com/llmrb/llm.rb/actions/runs/27511402478/job/81312014887 I hope this is helpful. I don't have more information except from the failed CI build. Thanks. ``` bundle exec rspec spec /home/runner/work/llm.rb/llm.rb/lib/llm/function/ractor/task.rb:69: warning: Ractor API is experimental and may change in future versions of Ruby. /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-support-3.13.7/lib/rspec/support/method_signature_verifier.rb:74: [BUG] Segmentation fault at 0x000000000000002c ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0074 p:---- s:0402 e:000401 l:y b:---- CFUNC c:0073 p:0007 s:0399 e:000396 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-support-3.13.7/lib/rspec/support/method_signature_verifier. c:0072 p:0008 s:0392 e:000391 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-support-3.13.7/lib/rspec/support/method_signature_verifier. c:0071 p:0003 s:0388 e:000387 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-support-3.13.7/lib/rspec/support/method_signature_verifier. c:0070 p:0024 s:0384 e:000383 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to. c:0069 p:0033 s:0378 e:000377 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to. c:0068 p:0018 s:0372 e:000371 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to. [FINISH] c:0067 p:---- s:0368 e:000367 l:y b:---- CFUNC :reject c:0066 p:0013 s:0364 e:000363 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to. c:0065 p:0007 s:0358 e:000357 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to. c:0064 p:0008 s:0353 e:000352 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/have_attrib c:0063 p:0013 s:0348 e:000347 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/have_attrib c:0062 p:0035 s:0343 e:000342 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/expectations/handler.rb:50 c:0061 p:0017 s:0338 e:000337 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/expectations/handler.rb:26 c:0060 p:0013 s:0331 e:000330 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/expectations/handler.rb:47 c:0059 p:0031 s:0323 e:000322 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/expectations/expectation_targ c:0058 p:0020 s:0316 e:000315 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/expectations/expectation_targ c:0057 p:0020 s:0309 e:000308 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/spec/openai/files_spec.rb:20 [FINISH] c:0056 p:---- s:0306 e:000305 l:y b:---- CFUNC :instance_exec c:0055 p:0021 s:0301 e:000300 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:263 c:0054 p:0002 s:0296 e:000295 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:511 c:0053 p:0002 s:0293 e:000292 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:468 c:0052 p:0002 s:0290 e:000289 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:486 c:0051 p:0002 s:0287 e:000286 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:626 c:0050 p:0018 s:0284 e:000283 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:352 c:0049 p:0004 s:0278 e:000277 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/webmock-3.24.0/lib/webmock/rspec.rb:39 [FINISH] c:0048 p:---- s:0274 e:000273 l:y b:---- CFUNC :instance_exec c:0047 p:0013 s:0269 e:000268 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:457 c:0046 p:0010 s:0263 e:000262 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:390 c:0045 p:0009 s:0257 e:000256 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:628 c:0044 p:0018 s:0254 e:000253 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:352 c:0043 p:0037 s:0248 E:000208 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:629 c:0042 p:0104 s:0241 E:0001c8 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:486 c:0041 p:0018 s:0234 E:0003f8 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:468 c:0040 p:0019 s:0229 E:001a38 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:511 c:0039 p:0076 s:0224 E:002698 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:259 c:0038 p:0047 s:0217 e:000216 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:653 [FINISH] c:0037 p:---- s:0211 e:000210 l:y b:---- CFUNC :map c:0036 p:0011 s:0207 e:000206 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:649 c:0035 p:0063 s:0202 e:000201 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:614 c:0034 p:0006 s:0193 e:000192 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:615 [FINISH] c:0033 p:---- s:0189 e:000188 l:y b:---- CFUNC :map c:0032 p:0076 s:0185 e:000184 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:615 c:0031 p:0007 s:0176 e:000175 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:121 [FINISH] c:0030 p:---- s:0172 e:000171 l:y b:---- CFUNC :map c:0029 p:0030 s:0168 e:000167 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:121 c:0028 p:0026 s:0165 e:000164 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/configuration.rb:2097 c:0027 p:0006 s:0161 e:000160 l:n b:---- BLOCK /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:116 c:0026 p:0009 s:0157 e:000156 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/reporter.rb:74 c:0025 p:0019 s:0152 e:000151 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:115 c:0024 p:0035 s:0145 e:000144 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:89 c:0023 p:0080 s:0139 e:000138 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:71 c:0022 p:0013 s:0131 e:000130 l:y b:0001 METHOD /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:45 c:0021 p:0010 s:0126 e:000125 l:y b:0001 TOP /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/exe/rspec:4 [FINISH] c:0020 p:---- s:0123 e:000122 l:y b:---- CFUNC :load c:0019 p:0098 s:0118 e:000117 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/rubygems.rb:305 c:0018 p:0075 s:0109 e:000108 l:y b:0001 TOP /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/bin/rspec:25 [FINISH] c:0017 p:---- s:0104 e:000103 l:y b:---- CFUNC :load c:0016 p:0064 s:0099 e:000098 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli/exec.rb:61 c:0015 p:0063 s:0093 e:000092 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli/exec.rb:24 c:0014 p:0048 s:0088 e:000087 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli.rb:504 c:0013 p:0054 s:0082 e:000081 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/vendor/thor/lib/thor/command.rb:28 c:0012 p:0040 s:0074 e:000073 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/vendor/thor/lib/thor/invocation.rb:127 c:0011 p:0246 s:0067 e:000066 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/vendor/thor/lib/thor.rb:538 c:0010 p:0008 s:0054 e:000053 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli.rb:35 c:0009 p:0055 s:0049 e:000048 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/vendor/thor/lib/thor/base.rb:584 c:0008 p:0022 s:0042 e:000041 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli.rb:29 c:0007 p:0041 s:0037 e:000036 l:n b:---- BLOCK /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/gems/4.0.0/gems/bundler-4.0.10/exe/bundle:28 c:0006 p:0007 s:0031 e:000030 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/friendly_errors.rb:118 c:0005 p:0051 s:0026 E:0014a8 l:y b:0001 TOP /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/gems/4.0.0/gems/bundler-4.0.10/exe/bundle:20 [FINISH] c:0004 p:---- s:0022 e:000021 l:y b:---- CFUNC :load c:0003 p:0098 s:0017 e:000016 l:y b:0001 METHOD /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/rubygems.rb:305 c:0002 p:0079 s:0008 E:000be0 l:n b:---- EVAL /opt/hostedtoolcache/Ruby/4.0.5/x64/bin/bundle:25 [FINISH] c:0001 p:0000 s:0003 E:0004a0 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /opt/hostedtoolcache/Ruby/4.0.5/x64/bin/bundle:25:in '<main>' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/rubygems.rb:305:in 'activate_and_load_bin_path' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/rubygems.rb:305:in 'load' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/gems/4.0.0/gems/bundler-4.0.10/exe/bundle:20:in '<top (required)>' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/friendly_errors.rb:118:in 'with_friendly_errors' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/gems/4.0.0/gems/bundler-4.0.10/exe/bundle:28:in 'block in <top (required)>' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli.rb:29:in 'start' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/vendor/thor/lib/thor/base.rb:584:in 'start' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli.rb:35:in 'dispatch' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/vendor/thor/lib/thor.rb:538:in 'dispatch' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/vendor/thor/lib/thor/invocation.rb:127:in 'invoke_command' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/vendor/thor/lib/thor/command.rb:28:in 'run' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli.rb:504:in 'exec' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli/exec.rb:24:in 'run' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli/exec.rb:61:in 'kernel_load' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/bundler/cli/exec.rb:61:in 'load' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/bin/rspec:25:in '<top (required)>' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/rubygems.rb:305:in 'activate_and_load_bin_path' /opt/hostedtoolcache/Ruby/4.0.5/x64/lib/ruby/4.0.0/rubygems.rb:305:in 'load' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/exe/rspec:4:in '<top (required)>' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:45:in 'invoke' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:71:in 'run' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:89:in 'run' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:115:in 'run_specs' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/reporter.rb:74:in 'report' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:116:in 'block in run_specs' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/configuration.rb:2097:in 'with_suite_hooks' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:121:in 'block (2 levels) in run_specs' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:121:in 'map' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/runner.rb:121:in 'block (3 levels) in run_specs' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:615:in 'run' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:615:in 'map' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:615:in 'block in run' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:614:in 'run' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:649:in 'run_examples' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:649:in 'map' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example_group.rb:653:in 'block in run_examples' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:259:in 'run' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:511:in 'with_around_and_singleton_context_hooks' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:468:in 'with_around_example_hooks' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:486:in 'run' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:629:in 'run_around_example_hooks_for' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:352:in 'call' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:628:in 'block (2 levels) in run_around_example_hooks_for' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:390:in 'execute_with' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:457:in 'instance_exec' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:457:in 'instance_exec' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/webmock-3.24.0/lib/webmock/rspec.rb:39:in 'block (2 levels) in <top (required)>' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:352:in 'call' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:626:in 'block in run_around_example_hooks_for' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/hooks.rb:486:in 'block in run' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:468:in 'block in with_around_example_hooks' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:511:in 'block in with_around_and_singleton_context_hooks' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:263:in 'block in run' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-core-3.13.6/lib/rspec/core/example.rb:263:in 'instance_exec' /home/runner/work/llm.rb/llm.rb/spec/openai/files_spec.rb:20:in 'block (3 levels) in <top (required)>' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/expectations/expectation_target.rb:101:in 'to' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/expectations/expectation_target.rb:65:in 'to' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/expectations/handler.rb:47:in 'handle_matcher' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/expectations/handler.rb:26:in 'with_matcher' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/expectations/handler.rb:50:in 'block in handle_matcher' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/have_attributes.rb:28:in 'matches?' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/have_attributes.rb:90:in 'respond_to_attributes?' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to.rb:78:in 'matches?' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to.rb:114:in 'find_failing_method_names' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to.rb:114:in 'reject' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to.rb:115:in 'block in find_failing_method_names' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to.rb:120:in 'matches_arity?' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-expectations-3.13.5/lib/rspec/matchers/built_in/respond_to.rb:180:in 'matches?' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-support-3.13.7/lib/rspec/support/method_signature_verifier.rb:344:in 'valid?' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-support-3.13.7/lib/rspec/support/method_signature_verifier.rb:375:in 'missing_kw_args' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rspec-support-3.13.7/lib/rspec/support/method_signature_verifier.rb:74:in 'missing_kw_args_from' rake aborted! Command failed with status (): [bundle exec rspec spec] /home/runner/work/llm.rb/llm.rb/Rakefile:41:in 'block in <top (required)>' /home/runner/work/llm.rb/llm.rb/vendor/bundle/ruby/4.0.0/gems/rake-13.4.2/exe/rake:27:in '<top (required)>' /opt/hostedtoolcache/Ruby/4.0.5/x64/bin/bundle:25:in '<main>' Tasks: TOP => default => spec (See full trace by running task with --trace) ................................................ ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125830] [Ruby Feature#22128] C API: Expose RB_OBJ_SET_FROZEN_SHAREABLE
by byroot (Jean Boussier) 25 Jun '26

25 Jun '26

Issue #22128 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22128: C API: Expose RB_OBJ_SET_FROZEN_SHAREABLE https://bugs.ruby-lang.org/issues/22128 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context I'm trying to experiment with adapting Active Record for a Ractor architecture. Since database connections can't possibly be Ractor shareable, the idea is to warp each connection inside its own ractor, and then send SQL queries and responses through a port. But for this to perform well, I'd like to directly build the query response as a fully shareable object, so that it can be pushed into the port for free, instead of having Ruby need to recursively walk the potentially large response to mark objects as shareable. Here's an example of how it would work in trilogy: https://github.com/byroot/trilogy/commit/5f58200b398995d2fc0d4673a5a6bbccd0… ### Problem Unfortunately, the necessary API isn't currently exposed in the C API: - `RB_OBJ_SET_FROZEN_SHAREABLE` - `RB_OBJ_SET_SHAREABLE` / `rb_obj_set_shareable` I understand that this API could potentially be misused, but given it's a C API, I believe it's acceptable to require care from the caller. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125833] [Ruby Bug#22129] error_highlight raises NotImplementedError for ArgumentErrors that get wrapped
by rwstauner (Randy Stauner) 25 Jun '26

25 Jun '26

Issue #22129 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22129: error_highlight raises NotImplementedError for ArgumentErrors that get wrapped https://bugs.ruby-lang.org/issues/22129 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- With code like ```ruby def x(y:) = y begin x rescue => e p e.exception("wat").detailed_message end ``` a NotImplementedError is raised on ruby 4.0+ ```/Users/rwstauner/.rubies/4.0.2/lib/ruby/4.0.0/error_highlight/base.rb:297:in 'ErrorHighlight::Spotter#spot': NotImplementedError (NotImplementedError) from /Users/rwstauner/.rubies/4.0.2/lib/ruby/4.0.0/error_highlight/base.rb:68:in 'ErrorHighlight.spot' from /Users/rwstauner/.rubies/4.0.2/lib/ruby/4.0.0/error_highlight/core_ext.rb:34:in 'ErrorHighlight::CoreExt#generate_snippet' from /Users/rwstauner/.rubies/4.0.2/lib/ruby/4.0.0/error_highlight/core_ext.rb:43:in 'ErrorHighlight::CoreExt#detailed_message' from tiny.rb:6:in 'Exception#full_message' from tiny.rb:6:in '<main>' tiny.rb:1:in 'Object#x': missing keyword: :y (ArgumentError) caller: tiny.rb:4 | x ^ callee: tiny.rb:1 | def x(y:) = y ^ from tiny.rb:4:in '<main>' ``` on ruby 3.4 it did not raise: ``` tiny.rb:1:in 'x': wat (ArgumentError) from tiny.rb:4:in '<main>' ``` seems related to https://bugs.ruby-lang.org/issues/21543 I have a PR up at https://github.com/ruby/error_highlight/pull/78 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125775] [Ruby Feature#22118] Introduce Basic Bit Operations into String
by hasumikin (hitoshi hasumi) 24 Jun '26

24 Jun '26

Issue #22118 has been reported by hasumikin (hitoshi hasumi). ---------------------------------------- Feature #22118: Introduce Basic Bit Operations into String https://bugs.ruby-lang.org/issues/22118 * Author: hasumikin (hitoshi hasumi) * Status: Open ---------------------------------------- This PR implements a subset of the specification proposed in the parent feature ticket #22082 PR URL: [placeholder to be updated] ## Methods implemented with the same specification as the parent ticket * `String#bit_at(offset, lsb_first: true) -> true | false | nil` * `String#bitwise_not -> String` * `String#bitwise_not! -> self` * `String#bitwise_and(other) -> String` * `String#bitwise_and!(other) -> self` * `String#bitwise_or(other) -> String` * `String#bitwise_or!(other) -> self` * `String#bitwise_xor(other) -> String` * `String#bitwise_xor!(other) -> self` ## Methods with range-oriented forms omitted for now The parent ticket also included range-oriented forms for some methods. In this PR, those range arguments are intentionally omitted, and the methods are limited to simpler forms. Range support can be considered as a future extension. * `String#bit_count -> Integer` * `String#bit_set(offset, lsb_first: true) -> self` * `String#bit_clear(offset, lsb_first: true) -> self` * `String#bit_flip(offset, lsb_first: true) -> self` In particular, `String#bit_count` currently takes no arguments. It does not accept a range, offset/length pair, or `lsb_first:` keyword. --- ## Remaining design questions even after narrowing the scope The overall direction of adding these methods has already been approved by Matz. The remaining questions are mostly about naming and API details. ### 1. Why the `bitwise_*` prefix is used In the parent ticket, all other methods are related to bit positions: they either take bit-position arguments, yield bit positions, or operate on a specified bit range. In contrast, the `bitwise_*` methods are whole-data operations. They apply to the entire string as a fixed-size bitmap and do not expose bit positions or bit ordering. The `bitwise_*` prefix is intended to make this distinction explicit. ### 2. Bit numbering #### `lsb_first: true` (default) Within each byte, `offset = 0` is the LSB. Numbering proceeds upward through byte[0] and then continues at the LSB of byte[1]: ```text byte[0] byte[1] offset: 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 bit: b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 ^ ^ LSB LSB offset = byte_index * 8 + bit_in_byte ``` #### `lsb_first: false` for MSB-first Byte order is preserved (`byte[0]` is still first), but within each byte numbering starts at the MSB: ```text byte[0] byte[1] offset: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 bit: b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 ^ ^ MSB MSB offset = byte_index * 8 + (7 - bit_in_byte) ``` * Whether `lsb_first:` is needed at all, or whether an equivalent mechanism should exist under another name? * If such a mechanism is needed, whether `lsb_first:` is the right keyword name? * If `lsb_first:` is acceptable, should its default be `true`? My point is that `lsb_first:` is needed because both bit numbering conventions are used in real byte-buffer formats. LSB-first is the more common convention for general in-memory bitmap use, including formats and APIs such as Apache Arrow validity bitmaps, ext4 block bitmaps, Roaring bitmaps, Linux/BSD bitmap APIs, and hardware register descriptions. MSB-first is also needed for domains such as RFC-style network protocol diagrams, PNG low-bit-depth scanlines, BitTorrent bitfields, and some compressed bit streams. The keyword only controls bit numbering within each byte. Byte order itself is unchanged. ### 3. Out-of-range behavior `String#bit_at` returns `nil` when the bit offset is out of range. On the other hand, mutating methods such as `String#bit_set`, `String#bit_clear`, and `String#bit_flip` raise `IndexError` for an out-of-range bit offset. This follows the same general distinction as read-like access versus write-like access: reading a missing position can return `nil`, but mutating a missing position should not silently do nothing. ### 4. Negative bit offsets Negative bit offsets are rejected with `IndexError`. Although Ruby often uses negative indices to count from the end, combining negative bit offsets with the `lsb_first: true/false` mechanism would make the numbering rule harder to explain and reason about. The API keeps bit offsets as non-negative flat positions from the beginning of the string. ### 5. Length mismatch for binary bitwise operations `String#bitwise_and`, `String#bitwise_or`, and `String#bitwise_xor` require both operands to have the same byte size. If the byte sizes differ, they raise `ArgumentError`. This avoids implicit truncation or zero-padding. Since these methods operate on strings as fixed-size bitmaps, requiring equal sizes makes the operation explicit and predictable. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125818] [Ruby Bug#22126] Stack underflow for partial DCE and loops
by viralpraxis (Iaroslav Kurbatov) 23 Jun '26

23 Jun '26

Issue #22126 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #22126: Stack underflow for partial DCE and loops https://bugs.ruby-lang.org/issues/22126 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-23T13:29:36Z master 13fe77dd2b) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` ruby ruby --parser prism -e 'if []; else; a => [*, 42, *]; end' -- raw disasm-------- trace: 1 0000 putnil ( 1) 0001 leave ( 1) <L018> [sp: 1, unremovable: 0, refcnt: 1] 0002 dup ( 1) 0003 topn 2 ( 1) 0005 opt_le <calldata:<=, 1> ( 1) 0007 branchunless <L021> ( 1) 0009 topn 3 ( 1) 0011 topn 1 ( 1) 0013 opt_aref <calldata:[], 1> ( 1) 0015 putobject 42 ( 1) 0017 dupn 2 ( 1) 0019 checkmatch 2 ( 1) 0021 dup ( 1) 0022 branchif <L023> ( 1) 0024 putspecialobject 1 ( 1) 0026 putobject "%p === %p does not return true" ( 1) 0028 topn 3 ( 1) 0030 topn 5 ( 1) 0032 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0034 setn 10 ( 1) 0036 putobject false ( 1) 0038 setn 12 ( 1) 0040 pop ( 1) 0041 pop ( 1) <L023> [sp: 4, unremovable: 0, refcnt: 1] 0042 setn 2 ( 1) 0044 pop ( 1) 0045 pop ( 1) 0046 branchif <L020> ( 1) 0048 putobject_INT2FIX_1_ ( 1) 0049 opt_plus <calldata:+, 1> ( 1) 0051 jump <L018> ( 1) <L021> [sp: 1, unremovable: 0, refcnt: 1] * 0053 adjuststack 3 ( 1) 0055 putspecialobject 1 ( 1) 0057 putobject "%p does not match to find pattern" ( 1) 0059 topn 2 ( 1) 0061 opt_send_without_block <calldata:core#sprintf, 2> ( 1) 0063 setn 4 ( 1) 0065 putobject false ( 1) 0067 setn 6 ( 1) 0069 pop ( 1) 0070 pop ( 1) 0071 jump <L012> ( 1) <L020> [sp: 1, unremovable: 0, refcnt: 1] 0073 adjuststack 3 ( 1) 0075 pop ( 1) 0076 jump <L003> ( 1) <L012> [sp: -1, unremovable: 0, refcnt: 1] 0078 pop ( 1) 0079 putspecialobject 1 ( 1) 0081 topn 4 ( 1) 0083 branchif <L024> ( 1) 0085 putobject NoMatchingPatternError ( 1) 0087 putspecialobject 1 ( 1) 0089 putobject "%p: %s" ( 1) 0091 topn 4 ( 1) 0093 topn 7 ( 1) 0095 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0097 opt_send_without_block <calldata:core#raise, 2> ( 1) 0099 jump <L025> ( 1) <L024> [sp: -1, unremovable: 0, refcnt: 1] 0101 putobject NoMatchingPatternKeyError ( 1) 0103 putspecialobject 1 ( 1) 0105 putobject "%p: %s" ( 1) 0107 topn 4 ( 1) 0109 topn 7 ( 1) 0111 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0113 topn 7 ( 1) 0115 topn 9 ( 1) 0117 opt_send_without_block <calldata:new, 3> ( 1) 0119 opt_send_without_block <calldata:core#raise, 1> ( 1) <L025> [sp: -1, unremovable: 0, refcnt: 1] 0121 adjuststack 7 ( 1) 0123 putnil ( 1) 0124 leave ( 1) <L003> [sp: -1, unremovable: 0, refcnt: 1] 0125 adjuststack 6 ( 1) 0127 putnil ( 1) 0128 leave ( 1) --------------------- -e:1: argument stack underflow (-2) -e: compile error (SyntaxError) ``` proposed patch: https://github.com/ruby/ruby/pull/17449 every version since 3.4.0-preview2 is affected -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125650] [Ruby Feature#22097] Add Proc#with_refinements
by shugo (Shugo Maeda) 23 Jun '26

23 Jun '26

Issue #22097 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22097: Add Proc#with_refinements https://bugs.ruby-lang.org/issues/22097 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- ## Abstract I propose `Proc#with_refinements` to support block-level refinements. ```ruby module StringExt refine String do def shout = upcase + "!" end end original = ->(s) { s.shout } refined = original.with_refinements(StringExt) p refined.call("hello") # "HELLO!" p original.call("hello") # NoMethodError ``` ## Background and Motivation I previously proposed `Proc#using` in [Feature #16461], but it introduced semantic complexities because it mutated existing blocks. Instead of mutating the existing block, `Proc#with_refinements` returns a new `Proc` object with its own isolated call sites. This approach makes its semantics much simpler than `Proc#using`, and it avoids thread-safety issues and plays nicely with inline caches. ## Limitation Similar to `Proc#binding`, `Proc#with_refinements` raises ArgumentError if the receiver is not created from a Ruby block. ```ruby :to_s.to_proc.with_refinements(StringExt) #=> ArgumentError ``` ## Implementation I've opened a pull request: https://github.com/ruby/ruby/pull/17248 A PoC for JRuby is also available at: https://github.com/shugo/jruby/pull/2 ### Data structure changes * Added a bit field `has_refinements` to `rb_proc_t`. * Added a hidden instance variable to `Proc` to store a `cref` with the applied refinements. * Added a single-entry cache `refinement_memo` to `rb_iseq_constant_body`. ### Deep copy of iseq and caching `Proc#with_refinements` performs a deep copy of the receiver's `iseq` to isolate its call sites from the original `Proc`. While a deep copy can be an expensive operation, the single-entry cache in `rb_iseq_constant_body` mitigates this overhead effectively for most practical use cases where the same refinements are applied repeatedly. ### Overhead for code not using Proc#with_refinements * Memory footprint: Neither internal structure grows in size. `has_refinements` is a 1-bit field added to rb_proc_t's existing bit field, and `refinement_memo` shares a union with `mandatory_only_iseq` in rb_iseq_constant_body. * Execution speed: The common `Proc#call` path is kept frameless and only adds a single `has_refinements` bit check. * GC: The mark/free/memsize functions add a single branch per `iseq` to select the union member. Benchmark results: https://gist.github.com/shugo/ddfe92f28ea31e6527a2f270e6daee7c Here's an excerpt from the results, where `compare-ruby` is master and `built-ruby` is the branch for this feature (focusing on Proc/Block operations): | |compare-ruby|built-ruby| |:------------------------------------|-----------:|---------:| |vm_proc | 47.215M| 46.149M| | | 1.02x| -| |vm_yield | 1.649| 1.754| | | -| 1.06x| -- https://bugs.ruby-lang.org/

3 8

[ruby-core:125796] [Ruby Feature#22121] Introduce Parallel Sweep feature
by luke-gru (Luke Gruber) 23 Jun '26

23 Jun '26

Issue #22121 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #22121: Introduce Parallel Sweep feature https://bugs.ruby-lang.org/issues/22121 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- ## Abstract Ruby's GC sweep implementation is currently incremental and lazy. This is to reduce pause times when sweeping. However, the sweep implementation doesn't take advantage of parallelism (multi-core). Sweeping in a GC is not an "embarassingly parallel" problem, but extra threads can help. I would like to introduce such a feature to Ruby so that users can take advantage of their multi-core CPUs to reduce GC pause times. ## Design I would like to have an additional "sweep thread" that sweeps alongside the Ruby GC thread (in parallel) and at the same time as Ruby code is running (concurrent). When the sweep thread is working alongside the Ruby GC thread, both threads grab pages from the current heap. If the sweep thread has already swept a page, the Ruby GC thread finishes it by clearing its bitmaps and adding the page to the free pages or empty pages lists. If there are no swept pages from the sweep thread, the Ruby GC thread sweeps a page by itself instead of waiting for swept pages. When an incremental sweep step is over, the sweep thread sweeps 1 incremental step's budget worth of slots while Ruby code is running. This is so that during the next incremental step, the Ruby GC thread just has to finish the pages off instead of sweeping the objects. ## Limitations Certain objects aren't safe to be freed by the sweep thread. T_DATA types from native extensions cannot be swept in general (although most are safe) because the user's sweep function may not be thread-safe. That function may modify global state in such a way that when it is called from both the sweep thread AND the Ruby GC thread at once, it behaves badly. In order to get around this, we introduce a new [TypedData flag](https://github.com/ruby/ruby/pull/17395). T_DATA internal to the VM mostly have this flag set, and native extension authors can set this flag if it is defined to allow their type to be swept concurrently. This feature is only available for the default GC. Ruby's MMTK garbage collector has its own implementation of concurrent sweeping that is not affected by this feature. This feature is only available for pthread platforms, although that restriction could be lifted with a bit of work. This feature is not on by default (see section `Building`). ## Implementation The [PR](https://github.com/ruby/ruby/pull/17411) is currently a draft, but it's in a working state. Please play with it and tell me what you think! ## Building ```bash ./configure --enable-parallel-sweep make -j ./ruby --enable-parallel-sweep -v #=> ruby 4.1.0dev (2026-06-19T15:49:17Z parallel-sweep cd7e59d45b) +PRISM +Parallel-Sweep [arm64-darwin25] ``` ## Benchmarks This image below is from running [ruby-bench](https://github.com/ruby/ruby-bench) `--headline` benchmarks 10 times and taking the median of means of the runs. The ruby-bench command was: ```bash ./run_benchmarks.rb --no-pinning --interleave --chruby="ruby_ctl::ruby_ctl --yjit" --chruby="psweep_lockfree::psweep_lockfree --yjit --enable-parallel-sweep" --headline ``` If you want sweep info per run, you can run it with the GC harness: ```bash ./run_benchmarks.rb --no-pinning --interleave --chruby="ruby_ctl::ruby_ctl --yjit" --chruby="psweep_lockfree::psweep_lockfree --yjit --enable-parallel-sweep" --harness=gc --headline ``` <img style="width: 1219px;" src="clipboard-202606191327-7umxq.png"><br> I encourage others to experiment with this feature, run your own benchmarks and share them here. When running your benchmarks, make sure not to pin the process to a CPU with `taskset`, otherwise the sweep thread will not run in parallel. > [!NOTE] > Sometimes there are regressions run to run. Run the benchmark 5-10 times to get more accurate results. > GC micro-benchmarks may not see any improvements or even slight regressions. The implementation targets a workload where there is sufficient time in between sweep steps for the sweep thread to do its work. > [!WARNING] > Benchmarking on MacOS tends to be less accurate than Linux. However, if that's all you have and want to share your results, please do. ## Future Work In the future, I would like it if we could process the metadata of a page in the sweep thread. For example, if we could clear the bitmaps and unlink an empty page, or even add a page to the free pages list then the Ruby pause time would get even smaller (or none at all). I did have a prototype of this, but it caused issues because it was creating too many empty pages too fast, and that had unintended consequences for the rest of the GC. I also believe parallel marking would have a large benefit. Major GCs take a long time due to marking, and if you have lots of threads of fibers than it takes even longer. Marking is a more naturally parallel problem, so would likely benefit from more than 1 worker thread. ---Files-------------------------------- clipboard-202606191327-7umxq.png (342 KB) -- https://bugs.ruby-lang.org/

2 4

[ruby-core:125811] [Ruby Bug#22125] IO::Buffer triggers use-after-free when it's freed/resized during enumeration
by hanazuki (Kasumi Hanazuki) 23 Jun '26

23 Jun '26

Issue #22125 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #22125: IO::Buffer triggers use-after-free when it's freed/resized during enumeration https://bugs.ruby-lang.org/issues/22125 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-23T09:56:24Z master 55945e5c98) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The block passed to `IO::Buffer#each` can free or resize the receiver (or its parent buffer when the reciver is a slice), which invalidates the memory region being iterated. The next iteration causes use-after-free. repro: ``` ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.free }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.resize(20) }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b1=b.slice; b1.each {|_, v| p v; b.free }' # No use-after-free but I think those should be errors too ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b1=b.slice; b1.each {|_, v| p v; b1.free }' ./miniruby -ve 'b=IO::Buffer.for("ruby"*10).dup; b.each {|_, v| p v; b.transfer }' ``` same for `#each_byte`. -- https://bugs.ruby-lang.org/

2 1