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

[ruby-core:126403] [Ruby Misc#9136] Deprecated Enumerator.new(object, method) bad for BasicObject
by Earlopain (Earlopain _) 16 Aug '26

16 Aug '26

Issue #9136 has been updated by Earlopain (Earlopain _). Status changed from Assigned to Closed It was removed in Ruby 3.0 ---------------------------------------- Misc #9136: Deprecated Enumerator.new(object, method) bad for BasicObject https://bugs.ruby-lang.org/issues/9136#change-118541 * Author: atlas (Atlas Prime) * Status: Closed * Assignee: zzak (zzak _) ---------------------------------------- =begin Documentation it says: In the second, deprecated, form, a generated Enumerator iterates over the given object using the given method with the given arguments passed. Use of this form is discouraged. Use Kernel#enum_for or Kernel#to_enum instead. e = Enumerator.new(ObjectSpace, :each_object) #-> ObjectSpace.enum_for(:each_object) But (({#enum_for})) and (({#to_enum})) are not available to subclasses of (({BasicObject})). In fact, I was defining (({#to_enum})) for a class that is a subclass of (({BasicObject})), and now I get warning of deprecation. =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117483] [Ruby master Bug#20419] [BUG] inconsistent freelist length with cppflags='-DRGENGC_CHECK_MODE -DUSE_RUBY_DEBUG_LOG=1'
by znz (Kazuhiro NISHIYAMA) 16 Aug '26

16 Aug '26

Issue #20419 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #20419: [BUG] inconsistent freelist length with cppflags='-DRGENGC_CHECK_MODE -DUSE_RUBY_DEBUG_LOG=1' https://bugs.ruby-lang.org/issues/20419 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- `TestGc#test_gc_stress_at_startup` failed on my environment, so I check which configure flags affect. How to reproduce: ``` ./configure cppflags='-DRGENGC_CHECK_MODE -DUSE_RUBY_DEBUG_LOG=1' make miniruby env RUBY_DEBUG=gc_stress ./miniruby -v ``` I can't reproduce with `cppflags='-DRGENGC_CHECK_MODE'` or `cppflags='-DUSE_RUBY_DEBUG_LOG=1'`. ---Files-------------------------------- output.txt (9.44 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126401] [Ruby Bug#11808] Different behavior between Enumerable#grep and Array#grep
by wanabe (_ wanabe) 16 Aug '26

16 Aug '26

Issue #11808 has been updated by wanabe (_ wanabe). Status changed from Assigned to Closed It has been fixed at 0a82bfe5e18ac86da72c27389db6eb8da156a0b5 == https://github.com/ruby/ruby/pull/7225 ``` $ cat a.rb class Test include Enumerable def each return enum_for(:each) unless block_given? yield "Hello" yield "World" end end enum = Test.new array = ["Hello", "World"] p enum.grep(/^(.)/) {$1} p array.grep(/^(.)/) {$1} $ git checkout 0a82bfe5e18ac86da72c27389db6eb8da156a0b5~ && make -j miniruby > /dev/null 2>&1 && ./miniruby a.rb HEAD is now at 2675f2c864f Remove whitespace [nil, nil] ["H", "W"] $ git checkout 0a82bfe5e18ac86da72c27389db6eb8da156a0b5 && make -j miniruby > /dev/null 2>&1 && ./miniruby a.rb Previous HEAD position was 2675f2c864f Remove whitespace HEAD is now at 0a82bfe5e18 use correct svar (#7225) ["H", "W"] ["H", "W"] ``` This commit is included in 3.3. Since 3.2 is end-of-life, there is no need to backport it. ---------------------------------------- Bug #11808: Different behavior between Enumerable#grep and Array#grep https://bugs.ruby-lang.org/issues/11808#change-118539 * Author: BenOlive (Ben Olive) * Status: Closed * Assignee: ko1 (Koichi Sasada) * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- Regex special global variables are available within the block for `Array#grep`, but are nil within the block for `Enumerable#grep`. Here is an example that explains it better: ~~~ruby class Test include Enumerable def each return enum_for(:each) unless block_given? yield "Hello" yield "World" end end enum = Test.new array = ["Hello", "World"] enum.grep(/^(.)/) {$1} # => [nil, nil] array.grep(/^(.)/) {$1} # => ["H", "W"] ~~~ Tested on 2.0.0, 2.1.5, & 2.2.2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116226] [Ruby master Bug#20189] `rb_str_resize` does not clear coderange when expanding
by tompng (tomoya ishida) 16 Aug '26

16 Aug '26

Issue #20189 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20189: `rb_str_resize` does not clear coderange when expanding https://bugs.ruby-lang.org/issues/20189 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.4.0dev (2024-01-09T07:07:19Z master db476cc71c) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Expanding string in some encoding (utf16 utf32) can change coderange to either valid or broken, but rb_str_resize does not clear coderange. This will cause a bug in c-extension libraries that use rb_str_resize. ~~~ruby # Example for stringio s = StringIO.new("\0".encode('UTF-16LE')) s.truncate(1); s.truncate(2); s.string.valid_encoding? #=> true s.truncate(1); s.string.valid_encoding?; s.truncate(2); s.string.valid_encoding? #=> false (expect to be true) ~~~ -- https://bugs.ruby-lang.org/

5 6

[ruby-core:114943] [Ruby master Bug#19910] Set#delete_if behavior inconsistent with Array/Hash
by segiddins (Samuel Giddins) 16 Aug '26

16 Aug '26

Issue #19910 has been reported by segiddins (Samuel Giddins). ---------------------------------------- Bug #19910: Set#delete_if behavior inconsistent with Array/Hash https://bugs.ruby-lang.org/issues/19910 * Author: segiddins (Samuel Giddins) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Given the following script: ```ruby #!/usr/bin/env ruby require 'set' def enum(collection) i = 0 collection.delete_if do i += 1 raise ArgumentError if i == 6 i.odd? end rescue ArgumentError return collection end pp enum([0, 1, 2, 3, 4, 5, 6, 7]) pp enum([0, 1, 2, 3, 4, 5, 6, 7].to_h { [_1, _1] }) pp enum([0, 1, 2, 3, 4, 5, 6, 7].to_set) ``` It results in: ``` [1, 3, 5, 6, 7] {1=>1, 3=>3, 5=>5, 6=>6, 7=>7} #<Set: {0, 1, 2, 3, 4, 5, 6, 7}> ``` As you can see, when an exception is raise inside `delete_if` on Hash/Array, the already-considered elements are still removed from the array. For `Set`, no elements are deleted (due to the implementation that builds up an intermediary list of elements to delete, then removes them from the underlying hash afterwards). It would be very helpful if `Set#delete_if` behaved consistently with other core collection types -- https://bugs.ruby-lang.org/

5 4

[ruby-core:125003] [Ruby Feature#21953] Allow accessing unshareable objects within a Ractor-local Ruby Box
by tikkss (Tsutomu Katsube) 16 Aug '26

16 Aug '26

Issue #21953 has been reported by tikkss (Tsutomu Katsube). ---------------------------------------- Feature #21953: Allow accessing unshareable objects within a Ractor-local Ruby Box https://bugs.ruby-lang.org/issues/21953 * Author: tikkss (Tsutomu Katsube) * Status: Open ---------------------------------------- ### Status Currently, non-main ractors prohibit access to the following objects to prevent data races: * Global variables * Class variables * Unshareable class instance variables * Unshareable constants ### Proposal I would like to propose that allow reading/writing unshareable objects inside a Ruby Box created in a non-main ractor: ```ruby # lib/x.rb class X # can write unshareable objects XXX = "1" @@cvar = "1" @ivar = "1" class << self def cvar; @@cvar; end def ivar; @ivar; end end end # can read unshareable objects $LOAD_PATH # => returns $LOAD_PATH includes lib directory X.cvar # => "1" X.ivar # => "1" X::XXX # => "1" # main.rb Ractor.new do local_box = Ruby::Box.new local_box.eval <<~RUBY base_dir = File.expand_path(File.dirname(__FILE__)) lib_dir = File.join(base_dir, "lib") # can write unshareable objects $LOAD_PATH.unshift(lib_dir) RUBY local_box.require("x") x = local_box::X.new end.join ``` Ruby Box can isolate global/class variables, class/module definitions from other boxes. A Ruby Box created inside a non-main ractor cannot be accessed from other ractor. If that is the case, wouldn’t it be fine to access unshareable objects inside that box? So I would like to propose that allow reading/writing unshareable objects inside a Ruby Box created in a non-main ractor. ### Background We are working on implementing a Ractor based parallel test runner for the test-unit gem. Ractor is a great for parallel processing. However, many existing libraries still rely on class variables or class instance variables for configuration. Ideally, we should reduce the use of class variables or class instance variables. Currently, we tried fixing several non-shareable objects, but we could not resolve all of them yet. We will continue working on this issue, but we are also exploring other approaches. This is the idea begind this proposal. I think the work needed to make objects shareable when running exisiting libraries with Ractor can be reduced. ### FAQ Q: Can we create a Ruby Box inside a non-main ractor? A: Yes: ```ruby Ractor.new {Ruby::Box.new}.join ``` Q: Is a Ruby Box created in a non-main ractor truly inaccessible from other ractor? A: No. I'm not sure if it's intentional, but a Ruby Box is a shareable object. Also, it can be accessed from the main Ractor by using `Ractor#value`: ```ruby Ractor.shareable?(Ruby::Box.new) # => true ``` ```ruby Ractor.new {Ruby::Box.new}.value # => #<Ruby::Box:3,user,optional> ``` To implement this proposal, Ruby Box may need to be an unshareable object, and passing it with `Ractor#value` may need to be disallowed. -- https://bugs.ruby-lang.org/

5 13

[ruby-core:126397] [Ruby Bug#22247] Add Ractor.movable?
by rkh (Konstantin Haase) 15 Aug '26

15 Aug '26

Issue #22247 has been reported by rkh (Konstantin Haase). ---------------------------------------- Bug #22247: Add Ractor.movable? https://bugs.ruby-lang.org/issues/22247 * Author: rkh (Konstantin Haase) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-15T07:21:53Z master d1c079751b) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Some objects cannot be moved (like unshareable lambdas). It would be great to have a method to check whether an object is movable, similar to `Ractor.shareable?`. Not 100% sure what it should return for shareable objects, but I would lean towards `true` as well (despite them not being moved), as they can be passed to `Ractor.send(object, move: true)`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125706] [Ruby Bug#22106] Getting a segfault when using finalizers and/or WeakMap in Ractors
by miles-georgi (Miles Georgi) 15 Aug '26

15 Aug '26

Issue #22106 has been reported by miles-georgi (Miles Georgi). ---------------------------------------- Bug #22106: Getting a segfault when using finalizers and/or WeakMap in Ractors https://bugs.ruby-lang.org/issues/22106 * Author: miles-georgi (Miles Georgi) * 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 ---------------------------------------- If I run the following script I get a segfault: ```ruby def ractor_and_port_counts total_ractor_count = total_ractor_port_count = open_ractor_count = open_ractor_port_count = 0 ObjectSpace.each_object do |object| case object when Ractor total_ractor_count += 1 open_ractor_count += 1 unless object.default_port.closed? when Ractor::Port total_ractor_port_count += 1 open_ractor_port_count += 1 unless object.closed? end end [total_ractor_count, open_ractor_count, total_ractor_port_count, open_ractor_port_count] end def show_ractor_counts GC.start pp ractor_and_port_counts end class Wrapper class << self def finalizer_proc proc do |id| wrapper_to_ractor = Ractor[:wrapper_to_ractor] if wrapper_to_ractor wrapper_to_ractor[id]&.each_key { |ractor| ractor << :close } rescue Ractor::ClosedError end end end def setup_finalizer(wrapper) wrapper_to_ractor = Ractor[:wrapper_to_ractor] ||= {} map = wrapper_to_ractor[wrapper.object_id] ||= ObjectSpace::WeakMap.new map[wrapper.ractor] = true ObjectSpace.define_finalizer(wrapper, &finalizer_proc) end end attr_reader :ractor def initialize(object) @ractor = Ractor.new do loop { break if receive == :close } o = nil end @ractor.send(object, move: true) self.class.setup_finalizer(self) end end class Outer def initialize = @inner = Wrapper.new(Inner.new) end class Inner; end show_ractor_counts outer = Wrapper.new(Outer.new) show_ractor_counts outer = nil # Removing the following line makes it so it only segfaults sometimes instead of everytime show_ractor_counts ``` I'll attach the script and the whole segfault but part of the segfault is: ``` <internal:gc>:44: [BUG] FL_FINALIZE flag is set, but finalizers are not found ruby 4.0.5 (2026-05-20 revision 64336ffd0e) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0004 p:0010 s:0023 e:000018 l:y b:0001 METHOD <internal:gc>:44 c:0003 p:0004 s:0011 e:000010 l:y b:0001 METHOD test_scripts/finalizer-in-ractor-test-segfault:23 c:0002 p:0075 s:0007 E:000f98 l:n b:---- EVAL test_scripts/finalizer-in-ractor-test-segfault:72 [FINISH] c:0001 p:0000 s:0003 E:000b40 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test_scripts/finalizer-in-ractor-test-segfault:72:in '<main>' test_scripts/finalizer-in-ractor-test-segfault:23:in 'show_ractor_counts' <internal:gc>:44:in 'start' ``` This happens in both a local build of 4.1-dev and 4.0.5 I suspect one might need to put GC.start at the end of the script if unable to reproduce. ---Files-------------------------------- segfault.txt (22 KB) finalizer-in-ractor-test-segfault (1.66 KB) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126364] [Ruby Bug#22240] Protect against SEGV caused by native extensions using rb_funcall between rb_protect and rb_jump_tag
by rwstauner (Randy Stauner) 14 Aug '26

14 Aug '26

Issue #22240 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22240: Protect against SEGV caused by native extensions using rb_funcall between rb_protect and rb_jump_tag https://bugs.ruby-lang.org/issues/22240 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- It's possible for native extensions do something like int state = 0; rb_protect(some_func, Qnil, &state); if (state) { rb_funcall(self, rb_intern("handler"), 0); rb_jump_tag(state); } If the ruby code in the rb_funcall has a rescue clause it will clear errinfo. When rb_jump_tag flows to hook_before_rewind with errinfo as Qnil it currently will SEGV. If I add a check to avoid the SEGV, the process then exits silently. If a native extension puts us in this state, the original message is gone. One thing we can do is detect this scenario and fabricate an exception. I have a PR up with a possible solution for this but am looking for feedback on the exception type and message or alternative suggestions for handling. I have reproduced this crash as far back as Ruby 3.3. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:126393] [Ruby Feature#22245] Reduce Array#& cost when self is much shorter than the argument
by andrey.samsonov＠gmail.com (Andrey Samsonov) 14 Aug '26

14 Aug '26

Issue #22245 has been reported by andrey.samsonov(a)gmail.com (Andrey Samsonov). ---------------------------------------- Feature #22245: Reduce Array#& cost when self is much shorter than the argument https://bugs.ruby-lang.org/issues/22245 * Author: andrey.samsonov(a)gmail.com (Andrey Samsonov) * Status: Open ---------------------------------------- # Abstract For intersections of larger arrays, Ruby builds a temporary hash from the argument to `Array#&`. As a result, `short & long` can be slower and use much more temporary memory than `long & short`. Callers cannot always choose the cheaper order because `Array#&` preserves the objects and order of `self`. This proposal reduces that operand-order cost when `self` is much shorter, making performance less dependent on which result order the caller needs. In a local test, `1000 & 10_000_000` reduced peak RSS from about 465 MB to about 94 MB. Benchmarks modeled on real call sites improved by about 1.7-2.7x. An unmodified Rails 8.1 Active Model benchmark improved by about 1.3x. `Array#intersection` uses the same C function and gets the same change. # Background When either array has more than 16 elements, Ruby uses a hash-based lookup and always builds the temporary hash from the argument. This creates a large cost difference between: ```ruby short & long long & short ``` The first expression hashes `long`. The second hashes `short`, but it can return elements in a different order. Some callers need the first expression because of that order. [Feature #17109] proposed removing the same operand-order cost by swapping the arrays. It was rejected because that changed the documented result order. This proposal instead preserves the objects and order from `self`. This proposal hashes `self` when it is at most half as long as the argument. It then scans the argument and returns matches in `self` order. For normal `#hash` and `#eql?` implementations, the result contains the same objects from `self`, in the same order, without duplicates. # Proposal ## Compatibility question May `Array#&` and `Array#intersection` choose which array to hash based on their lengths? The result stays the same for built-in values and custom equality methods where `#eql?` is an equivalence relation, equal elements have equal `#hash` values, and both methods are stable, have no side effects, and return normally. For stable, side-effect-free methods, both hash-based paths make the same number of `#hash` calls. The receiver, order, and number of `#eql?` calls can change. Mutation or exceptions can also change how many calls complete. The patch makes the RDoc direction-neutral. `Array#intersect?` has chosen the hash side by length since Ruby 3.1. This is relevant precedent, although `intersect?` returns only a boolean. This patch also preserves the objects and order from `self`. ## Implementation When `len(self) <= len(argument) / 2`, and the arrays use the hash-based path: 1. Build a hash from the distinct elements of `self`. 2. Keep their first positions in `self`. 3. Scan the argument and mark each match. 4. Return the marked elements in `self` order. Small arrays, near-equal arrays, and a long `self` with a short argument keep the current path. `Array#|` is not changed because its operand-order cost has a different cause. `Array#-` preserves repeated unmatched elements and needs a separate algorithm and compatibility analysis. ## Why start at 2x? The 2x threshold is an empirical starting point, not part of the API. Forced-threshold benchmarks gave mixed results below 2x. At 2x, all tested cases with distinct argument elements improved, with median gains of about 1.1-1.3x. I would welcome maintainer guidance on whether Ruby has an established method or relevant precedent for selecting thresholds like this. # Use cases - In Rails 8.1, `Array(only).map(&:to_s) & attribute_names` in `ActiveModel::Serialization#serializable_hash` filters a full attribute list with keys from the caller. - In Rails 8.1, Active Record collection replacement calls `intersection(new_target, original_target)`. The ordinary `HasManyAssociation` helper implements this as `a & b`; `HasManyThroughAssociation` uses a separate implementation. - Rails command lookup uses `lookups & namespaces.keys`. # Discussion ## Results The primary measurements ran on macOS arm64, with separate confirmation on Ubuntu 24.04 x86-64. Each comparison used the same Ruby commit with and without the patch. | Case | Benchmark case | Change | |---|---|---:| | ActiveModel shape, 6 and 50 strings | `attr-filter-6-and-50` | ~1.77x | | Collection replacement shape, 10 and 10,000 ids | `short-receiver-10-and-10k` | ~2.74x | On Linux, the same two shapes improved by 1.66x and 2.46x. Other id-list shapes moved by 1.11-1.23x there, but unchanged small-array cases moved by up to 1.16x in the same rounds, so I make no claim from those smaller deltas. With unmodified Rails 8.1 Active Model code, `ActiveModel#serializable_hash(only: 6 of 50 attributes)` improved from about 3.6 µs to about 2.8 µs per call. The control path without `only:` did not change. For memory, `1000 & 10_000_000` reduced peak RSS from about 465 MB to about 94 MB. The scan still takes time proportional to the long array; the change removes the hash build from that array. The Rails 8.1.1 Lobsters workload entered the proposed branch 152 times across application boot and three iterations, mainly through Active Model serialization. Six alternating A/B batches found no detectable whole-workload change. ## Known trade-offs ### Arguments with many duplicates The threshold uses array lengths, not the number of distinct elements. A long argument with few distinct values can be cheap to hash. In tested cases at the exact `2x` threshold, throughput fell to about 0.64x on arm64 and about 0.90x on Linux. The mirrored case is slow on current Ruby: a short duplicate-heavy `self` with a long distinct argument improved by about 2.4x on arm64 and 1.6x on Linux with this patch. No choice based only on lengths can make both shapes faster. ### Hash collisions The new path makes hash quality on `self` more important; the current path makes hash quality on the argument more important. The worst-case complexity does not change, but the array that triggers it can change at the threshold. For example, 3,000 distinct elements in `self` with the same hash and a clean 6,000-element argument changed from about 0.5 ms to 63 ms. The reverse case changed from about 250 ms to 0.8 ms. `Array#intersect?` already makes the same trade when it chooses the shorter array. ### Custom `#hash` and `#eql?` Built-in integers, symbols, and strings cannot observe the call direction. User-defined methods can. The standard library provides an example with asymmetric `#eql?`: ```ruby require "delegate" string = "abc" delegator = SimpleDelegator.new(string) delegator.hash == string.hash # => true delegator.eql?(string) # => true string.eql?(delegator) # => false a = [delegator] + (1..20).map { |i| "x#{i}" } b = [string] + (1..100).map { |i| "y#{i}" } a & b # Current Ruby: [delegator], proposal: [] a.intersect?(b) # Current Ruby and proposal: false b & a # Current Ruby and proposal: [] ``` The proposal changes the first result and makes these three operations agree for this input. This agreement is not a compatibility guarantee. For values whose `#eql?` is symmetric, transitive, stable, and consistent with `#hash`, the result does not change. Logging, mutation, exceptions, object reachability, and GC timing can expose a different call order. These behaviors are not specified. ## Safety and tests Calls to user `#hash` and `#eql?` can mutate either array or run the GC. The candidate loop cannot write past the initial length of `self`. Candidate objects live in a Ruby array; the only raw buffer contains `bool` flags. Tests cover the `2x` boundary, both lookup paths, equality edge cases, mutation, and GC compaction. `ruby/test_array.rb` and `spec/ruby/core/array` pass. A randomized comparison with current Ruby produced the same results for normal values. Implementation: [one-commit fork branch](https://github.com/ruby/ruby/compare/master...kryzhovnik:array-and-…. It contains the change, the RDoc update, the tests, and the benchmarks. # See also - [ruby/ruby#14855](https://github.com/ruby/ruby/pull/14855) also chose an array by length, but did not preserve both the objects and order from `self`. - [Feature #15198] added `Array#intersect?`, which avoids materializing an intersection and can choose the hash side by length because it returns only a boolean. - [Feature #13884] added an existing size-based strategy choice for these methods. - [Bug #19622] led Ruby to document that these methods use both `#hash` and `#eql?`; it did not specify which operand receives the calls. -- https://bugs.ruby-lang.org/

1 0