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

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

08 May '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/

4 8

[ruby-core:125235] [Ruby Bug#21991] `$!` stays as the first exception in Ruby Box
by tikkss (Tsutomu Katsube) 08 May '26

08 May '26

Issue #21991 has been reported by tikkss (Tsutomu Katsube). ---------------------------------------- Bug #21991: `$!` stays as the first exception in Ruby Box https://bugs.ruby-lang.org/issues/21991 * Author: tikkss (Tsutomu Katsube) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Description --- When Ruby Box is enabled (`RUBY_BOX=1`), `$!` inside `rescue` does not change after the first exception. `$!` is expected to show the exception for each `rescue` block, but it always shows the first one. Steps to reproduce --- ```ruby # test.rb begin raise "First error" rescue pp $! end begin raise "Second error" rescue pp $! end begin raise "Third error" rescue pp $! end ``` Expected result --- ```console $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. #<RuntimeError: First error> #<RuntimeError: Second error> #<RuntimeError: Third error> ``` Actual result --- ```console $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. #<RuntimeError: First error> #<RuntimeError: First error> #<RuntimeError: First error> ``` Additional information --- This issue does not reproduce when `RUBY_BOX=1` is not set: ```console $ ruby test.rb #<RuntimeError: First error> #<RuntimeError: Second error> #<RuntimeError: Third error> ``` Also, this issue does not reproduce when the exception object is captured explicitly in the `rescue` clause: ```ruby # test.rb begin raise "First error" rescue => e pp e end begin raise "Second error" rescue => e pp e end begin raise "Third error" rescue => e pp e end ``` ```console $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. #<RuntimeError: First error> #<RuntimeError: Second error> #<RuntimeError: Third error> ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125397] [Ruby Bug#22021] Array#delete_if may delete wrong object if array has been altered already
by chucke (Tiago Cardoso) 05 May '26

05 May '26

Issue #22021 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #22021: Array#delete_if may delete wrong object if array has been altered already https://bugs.ruby-lang.org/issues/22021 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: 4.0.2 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The simplest example I can come up with: ```ruby $ar = ar = [1, 2, 3, 4, 5] def delete_at(i) $ar.delete(i) end ar.delete_if { |i| i == 2 ? (delete_ar(i) && true) : false } ar #=> [1, 4, 5], and it should be [1, 3, 4, 5] ``` -- https://bugs.ruby-lang.org/

2 4

[ruby-core:125403] [Ruby Bug#22023] Backport commits cba70c3532c34803bae065745b799103635ec67a and cfdca23bfecb5fb74fd31128ac37d734d8e7e43b
by byroot (Jean Boussier) 05 May '26

05 May '26

Issue #22023 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #22023: Backport commits cba70c3532c34803bae065745b799103635ec67a and cfdca23bfecb5fb74fd31128ac37d734d8e7e43b https://bugs.ruby-lang.org/issues/22023 * Author: byroot (Jean Boussier) * Status: Closed * Backport: 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- - Fix passing frozen_string_literal option to #compile_file backed by Prism: https://github.com/ruby/ruby/pull/16779 - ISeq.compile_file was not switching on parser: https://github.com/ruby/ruby/pull/16463 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125377] [Ruby Bug#22018] ISeq created via `RubyVM::InstructionSequence.compile` don't support coverage
by byroot (Jean Boussier) 05 May '26

05 May '26

Issue #22018 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #22018: ISeq created via `RubyVM::InstructionSequence.compile` don't support coverage https://bugs.ruby-lang.org/issues/22018 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.3: WONTFIX, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Reproduction: ```ruby require "coverage" File.write("/tmp/a.rb", <<~RUBY) module CoverableRaw def self.call "cover up" end end CoverableRaw.call RUBY Coverage.start require "/tmp/a.rb" p Coverage.result File.write("/tmp/b.rb", <<~RUBY) module Coverable def self.call "cover up" end end Coverable.call RUBY class RubyVM::InstructionSequence def self.load_iseq(path) compile_file(path) end end Coverage.start require "/tmp/b.rb" p Coverage.result ``` Expected: ```ruby {"/tmp/a.rb" => [1, 1, 1, nil, nil, nil, 1]} {"/tmp/b.rb" => [1, 1, 1, nil, nil, nil, 1]} ``` Actual: ```ruby {"/tmp/a.rb" => [1, 1, 1, nil, nil, nil, 1]} {} ``` Patch: https://github.com/ruby/ruby/pull/16805 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125396] [Ruby Bug#22020] Inner call node without all arguments returned by RubyVM::AbstractSyntaxTree.of for call with a block
by Eregon (Benoit Daloze) 04 May '26

04 May '26

Issue #22020 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #22020: Inner call node without all arguments returned by RubyVM::AbstractSyntaxTree.of for call with a block https://bugs.ruby-lang.org/issues/22020 * Author: Eregon (Benoit Daloze) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby begin foo(1, 2, kw: :arg) { 42 } rescue => e pp RubyVM::AbstractSyntaxTree.of e.backtrace_locations[0] end ``` ``` $ ruby --parser=parse.y rubyvm_ast_node_id_loc.rb (FCALL@2:2-2:21 :foo (LIST@2:6-2:20 (INTEGER@2:6-2:7 1) (INTEGER@2:9-2:10 2) (HASH@2:12-2:20 (LIST@2:12-2:20 (SYM@2:12-2:15 :kw) (SYM@2:16-2:20 :arg) nil)) nil)) ``` That covers `foo(1, 2, kw: :arg)` so all arguments except the block argument, which looks inconsistent. I believe it should be: ``` $ ruby --parser=parse.y rubyvm_ast_node_id_loc.rb (ITER@2:2-2:28 (FCALL@2:2-2:21 :foo (LIST@2:6-2:20 (INTEGER@2:6-2:7 1) (INTEGER@2:9-2:10 2) (HASH@2:12-2:20 (LIST@2:12-2:20 (SYM@2:12-2:15 :kw) (SYM@2:16-2:20 :arg) nil)) nil)) (SCOPE@2:22-2:28 tbl: [] args: nil body: (INTEGER@2:24-2:26 42))) ``` PR: https://github.com/ruby/ruby/pull/16836 -- https://bugs.ruby-lang.org/

1 2

[ruby-core:125150] [Ruby Bug#21970] Corrupted `ciobj->operands` in `compile.c: optimize_checktype`
by byroot (Jean Boussier) 04 May '26

04 May '26

Issue #21970 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21970: Corrupted `ciobj->operands` in `compile.c: optimize_checktype` https://bugs.ruby-lang.org/issues/21970 * Author: byroot (Jean Boussier) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A rare crash I observed in production. I unfortunately don't have a reproduction, but perhaps this will ring a bell to someone. ``` #4 0x0000aaaac9afb1b8 [PAC] in sigsegv (sig=11, info=0xaaaaff573e30, ctx=0xaaaaff573eb0) at signal.c:948 #5 <signal handler called> #6 0x0000aaaac9ddcb60 in get_next_insn (iobj=0xffffffff00000001) at compile.c:3078 #7 optimize_checktype (iobj=0xaaab00000640, iseq=0xffff6e41ac80) at compile.c:3291 #8 iseq_peephole_optimize (iseq=iseq@entry=0xffff6e41ac80, list=list@entry=0xaaab00000640, do_tailcallopt=do_tailcallopt@entry=0) at compile.c:3363 #9 0x0000aaaac9dde590 [PAC] in iseq_optimize (anchor=<optimized out>, iseq=<optimized out>) at compile.c:4453 #10 iseq_setup_insn (anchor=<optimized out>, iseq=<optimized out>) at compile.c:1648 #11 iseq_setup_insn (iseq=0xffff6e41ac80, anchor=0xffffdb42d078) at compile.c:1637 #12 0x0000aaaac9e22d34 [PAC] in pm_iseq_compile_node (iseq=0xffff6e41ac80, node=<optimized out>) at /ruby-4.0.2/prism_compile.c:10514 #13 0x0000aaaac9a32f08 [PAC] in pm_iseq_new_with_opt_try (d=d@entry=281474360333120) at iseq.c:1106 #14 0x0000aaaac99c81bc [PAC] in rb_protect (proc=proc@entry=0xaaaac9a32eec <pm_iseq_new_with_opt_try>, data=data@entry=281474360333120, pstate=pstate@entry=0xffffdb42d3e4) at eval.c:1127 #15 0x0000aaaac9a39408 [PAC] in pm_iseq_new_with_opt (node=node@entry=0xffffdb42d510, name=name@entry=281472546599520, path=path@entry=281472531544280, realpath=281472531544280, first_lineno=first_lineno@entry=215, parent=parent@entry=0x0, isolated_depth=isolated_depth@entry=0, type=type@entry=ISEQ_TYPE_METHOD, option=0xffffdb42d328, error_state=error_state@entry=0xffffdb42d3e4) at iseq.c:1159 #16 0x0000aaaac9dcf1fc [PAC] in pm_new_child_iseq (iseq=iseq@entry=0xffff6e41b068, node=node@entry=0xffffdb42d510, name=281472546599520, parent=parent@entry=0x0, type=type@entry=ISEQ_TYPE_METHOD, line_no=215) at /ruby-4.0.2/iseq.h:154 #17 0x0000aaaac9e0688c [PAC] in pm_compile_node (iseq=iseq@entry=0xffff6e41b068, node=0xaaab000f0ac0, ret=ret@entry=0xffffdb42dcd8, popped=popped@entry=true, scope_node=scope_node@entry=0xffffdb42e170) at /ruby-4.0.2/prism_compile.c:9073 #18 0x0000aaaac9e0bd7c [PAC] in pm_compile_node (iseq=iseq@entry=0xffff6e41b068, node=0xaaab000eeed0, ret=ret@entry=0xffffdb42dcd8, popped=popped@entry=false, scope_node=scope_node@entry=0xffffdb42e170) at /ruby-4.0.2/prism_compile.c:10327 #19 0x0000aaaac9e1ee4c [PAC] in pm_compile_scope_node (iseq=iseq@entry=0xffff6e41b068, scope_node=scope_node@entry=0xffffdb42e170, ret=ret@entry=0xffffdb42dcd8, popped=popped@entry=false, node_location=<optimized out>, node_location=<optimized out>) at /ruby-4.0.2/prism_compile.c:7047 ``` ``` (gdb) f 7 #7 optimize_checktype (iobj=0xaaab00000640, iseq=0xffff6e41ac80) at compile.c:3291 3291 ciobj = (INSN *)get_next_insn((INSN*)OPERAND_AT(ciobj, 0)); (gdb) p (INSN*)ciobj->operands[0] $7 = (INSN *) 0xffffffff00000001 (gdb) p *(INSN*)ciobj->operands[0] Cannot access memory at address 0xffffffff00000001 ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:125398] [Ruby Bug#22022] Refinement zsuper problems when referenced method changes
by jeremyevans0 (Jeremy Evans) 04 May '26

04 May '26

Issue #22022 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #22022: Refinement zsuper problems when referenced method changes https://bugs.ruby-lang.org/issues/22022 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-03T23:57:21Z master d8d2ed5dc9) +PRISM [x86_64-openbsd7.8] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've found many problems with refinement zsuper methods. Here's one example: ```ruby module M private def a = :a alias a a end class A include M end class B < A end module R refine B do public :a end end using R B.new.a # false() function is unimplemented on this machine (NotImplementedError) ``` Here's another: ```ruby class A private def a = :a end module R refine A do public :a end end using R A.new.a # => :a module M def a = :b end A.prepend M A.new.a # SystemStackError: stack level too deep ``` The problematic cases are in general can be broken down into: * Method being redefined (in same or closer ancestor) * Method being removed * Method being undef-ed (in same or closer ancestor) * Method being overridden by method in included module * Method being overridden by method in prepended module * Method being defined in an included/prepended module at time of refinement In addition to the `NotImplementedError` and `SystemStackError`, there are other cases where incorrect results are given. One possible approach for fixing this is to turn the zsuper methods into regular methods that call super . This fixes all cases that I found. This is not a perfect solution, due to mildly worse performance (I'm guessing) as well as arity/parameters for the method not as helpful. It may possible to avoid these issues by clearing method caches in more cases. However, I think that would require a lot of extra work, since you cannot just clear the method cache for the current class. You would need to clear it for all subclasses, if this is a module, do the same for all classes that include/prepend the module, as well as any subclasses of those classes. Considering the need for refinement zsuper methods is very rare, the performance and arity/parameters issues seem acceptable (to me). Pull request: https://github.com/ruby/ruby/pull/16844 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124714] [Ruby Bug#21870] Regexp: Warnings when using multiple non-overlapping \p{...} classes
by jneen (Jeanine Adkisson) 03 May '26

03 May '26

Issue #21870 has been reported by jneen (Jeanine Adkisson). ---------------------------------------- Bug #21870: Regexp: Warnings when using multiple non-overlapping \p{...} classes https://bugs.ruby-lang.org/issues/21870 * Author: jneen (Jeanine Adkisson) * Status: Open * ruby -v: 4.0.0, 4.0.1, earlier versions to a lesser extent * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby $VERBOSE = true # warning: character class has duplicated range: /[\p{Word}\p{S}]/ regex = /[\p{Word}\p{S}]/ ``` As far as I can tell this is a perfectly valid and non-overlapping set of unicode properties, but I am still being spammed with warnings. Using `/(\p{Word}|\p{S})/` is kind of a workaround, but it is slower. -- https://bugs.ruby-lang.org/

9 22

[ruby-core:125265] [Ruby Feature#21998] Add {Method,UnboundMethod,Proc}#source_range
by Eregon (Benoit Daloze) 02 May '26

02 May '26

Issue #21998 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21998: Add {Method,UnboundMethod,Proc}#source_range https://bugs.ruby-lang.org/issues/21998 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I'm using matz's suggestion almost as-is from https://bugs.ruby-lang.org/issues/6012#note-53. The only change is the proposed class name. ## Use Cases Use cases have been discussed extensively and matz said: > The use cases are real and I want to support them So I think we don't need to discuss that anymore :) ## Background Adding column and last line information to `#source_location` is deemed too incompatible given the usages of `obj.source_location.last` which expect the start line (they would get the end column instead). ## Proposal So instead we add a new method, `{Method,UnboundMethod,Proc}#source_range`, which returns a `Ruby::SourceRange` and has these methods: * `start_line`: 1-indexed (same as `source_location.first`) * `end_line`: 1-indexed * `start_column`: in bytes, 0-indexed, I think `start_byte_column` could be good for extra clarity * `end_column`: in bytes, 0-indexed, I think `end_byte_column` could be good for extra clarity * `inspect` which shows something like `#<Ruby::SourceRange (1,0)-(2,10)>`. For the edge case of a heredoc spanning further than the end of a method/block, we would not include it in the `end_line` & `end_column` methods, but instead document it and provide a small code snippet in the docs to compute that if desired with Prism. ## Alternative An alternative could be a `Ruby::SourceLocation` class and `obj.source_location(object: true)`/`obj.source_location(extended: true)` but it feels less nice. Since we are designing something new I think it's best to go for the cleanest design. ## Consistency The above methods match the name of methods on `Prism::Node` and have the same semantics, which is good for consistency and to avoid confusion. ## Scope The scope is intentionally minimal to keep the discussion focused. ## Implementation I'm happy to implement this, it should be pretty trivial and very similar to the extended `source_location`. I would prefer to get an approval for this feature before implementing. -- https://bugs.ruby-lang.org/

6 18