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

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

09 Jul '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 22

[ruby-core:125586] [Ruby Feature#22085] `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings
by byroot (Jean Boussier) 09 Jul '26

09 Jul '26

Issue #22085 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22085: `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings https://bugs.ruby-lang.org/issues/22085 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Ruby issue warnings when parsing out of range floats, e.g.: ``` $ ruby -We '1e184467440737095516160.to_s' -e:1: warning: Float 1e184467440737095516... out of range ``` This makes a lot of sense for float literals parsed by the Ruby parser. However I'm not convinced it makes sense when parsing user input or third party data: ```ruby >> '1e184467440737095516160'.to_f (irb):1: warning: Float 1e184467440737095516... out of range => Infinity >> Float('1e184467440737095516160') <internal:kernel>:196: warning: Float 1e184467440737095516... out of range => Infinity ``` As these warnings aren't really actionable in most cases. So I think `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:124984] [Ruby Bug#21951] Lazy load error enhancer gems to speed up boot time
by hsbt (Hiroshi SHIBATA) 09 Jul '26

09 Jul '26

Issue #21951 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21951: Lazy load error enhancer gems to speed up boot time https://bugs.ruby-lang.org/issues/21951 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Summary I investigate https://github.com/ruby/rubygems/issues/3799 for speed up Ruby's boot time. It depends on the environment, but when gems are included in `GEM_HOME` and user installation. I and Claude found that the most time-consuming part is requiring the three gems related to error notification, rather than loading the gemspec of default gems. ## How it works Defer loading of `error_highlight`, `did_you_mean`, and `syntax_suggest` from boot time to first error display. These gems only enhance `Exception#detailed_message`, so they are not needed until an error is actually displayed. ## Performance `ruby -e1` boot time on Apple M1 Pro: | Configuration | With user gems | Default gems only | |---|---|---| | master | 114.3 ms | 38.3 ms | | This patch | 30.2 ms | 30.4 ms | | `--disable-did_you_mean --disable-error_highlight --disable-syntax_suggest` | 30.3 ms | 30.6 ms | With this patch, `ruby -e1` is as fast as disabling all three gems via flags. The error path has no measurable regression (+0.9 ms, within noise). ## Patch https://github.com/ruby/ruby/pull/16371 -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123883] [Ruby Feature#21704] Expose rb_process_status_new to C extensions
by noteflakes (Sharon Rosner) 09 Jul '26

09 Jul '26

Issue #21704 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Feature #21704: Expose rb_process_status_new to C extensions https://bugs.ruby-lang.org/issues/21704 * Author: noteflakes (Sharon Rosner) * Status: Open ---------------------------------------- A fiber scheduler implementation with a hook for `#process_wait` needs to return a `Process::Status` object, but currently it is not possible for a C extension to directly create an instance of `Process::Status`. The technique currently used in various fiber scheduler implementations is to use `pidfd_open`, poll for fd readiness, then call `Process::Status.wait`, which creates the instance. On recent Linux kernels (6.7 or newer), `io_uring_prep_waitid` can be used to directly wait for process termination, which provides us with the pid and status of the terminated child process, but there's no way to directly create an instance of `Process::Status`, required for implementing the `#process_wait` hook. Exposing the internal `rb_process_status_new` function would allow such an implementation. Using `io_uring_prep_waitid` would also lead to better compatibility of fiber schedulers with calls to `Process.wait(0)` or `Process.wait(-1)`, as those cannot be done using `pidfd_open`. The associated PR is here: https://github.com/ruby/ruby/pull/15213 An working fiber scheduler implementation of `process_wait` using `io_uring_prep_waitid` has been submitted here: https://github.com/socketry/io-event/pull/154 -- https://bugs.ruby-lang.org/

4 4

[ruby-core:125590] [Ruby Bug#22086] Backport Marshal overflow fix
by nobu (Nobuyoshi Nakada) 09 Jul '26

09 Jul '26

Issue #22086 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22086: Backport Marshal overflow fix https://bugs.ruby-lang.org/issues/22086 * Author: nobu (Nobuyoshi Nakada) * Status: Closed * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- GH-17130 * commit:8ed456afc95ccb23256fe10036cd0d9678ceb245 Marshal.load: Fix buffer overflow at overread * commit:2510dfee2a6aba9e99664b453e2be69e00eb21a6 Marshal.load: Fix integer overflow of length * commit:3f6d6c0373d2cb005f7cf164414cbb531f42d525 Marshal.load: Check bignum sign -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124833] [Ruby Bug#21882] IO::Buffer#locked leaves the buffer locked when the block raises
by hanazuki (Kasumi Hanazuki) 09 Jul '26

09 Jul '26

Issue #21882 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #21882: IO::Buffer#locked leaves the buffer locked when the block raises https://bugs.ruby-lang.org/issues/21882 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `IO::Buffer#locked` should unlock the buffer even after the block raises an exception. ```ruby buf = IO::Buffer.new(100) buf.locked { fail } rescue nil buf.locked { p :ok } # expected to print :ok, but actually raises a LockedError ``` -- https://bugs.ruby-lang.org/

5 6

[ruby-core:123795] [Ruby Bug#21685] Unnecessary context-switching, especially bad on multi-core machines.
by jpl-coconut (Jacob Lacouture) 09 Jul '26

09 Jul '26

Issue #21685 has been reported by jpl-coconut (Jacob Lacouture). ---------------------------------------- Bug #21685: Unnecessary context-switching, especially bad on multi-core machines. https://bugs.ruby-lang.org/issues/21685 * Author: jpl-coconut (Jacob Lacouture) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- While debugging a performance issue in a large rails application, I wrote a minimal microbenchmark that reproduces the issue. [[here]](https://gist.github.com/jpl-coconut/cb3679ce885eb578e1071c4b3a525d5c) I was surprised to see that the benchmark takes ~3.6sec on a single-core machine, and ~36sec **(10x slower) on a machine with 2 or more cores** . Initially I thought this was a bug in the implementation of Thread::Queue, but soon realized it relates to how the ruby reschedules threads around system calls. I prepared a fix in [[this branch]](https://github.com/jpl-coconut/ruby/tree/deferred_thread_wait) which is based off ruby 3.4.7. I can apply the fix to a different branch or to master if that's helpful. The fix simply defers suspending the thread until the syscall has been running for some short interval. I chose 100usec initially, but this could easily be made configurable. I pasted raw benchmark results below from a single run (though I did many runs and the results are stable). My CPU is an Apple M4. After the fix: - Single-core performance improves by 55%, from 3.6sec to 2sec. - Adding cores causes performance to be flat (at 2sec), rather than getting 10x slower. - Multi-core context-switch count reduces by 99.995%, from 1.4 million to ~80 - system_time/user_time ratio drops from (1.2 - 1.6) to 0.65 Here are the benchmark results before my change: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1140773 nonvoluntary_ctxt_switches: 9487 real 0m3.619s user 0m1.653s sys 0m1.950s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1400110 nonvoluntary_ctxt_switches: 3 real 0m36.223s user 0m9.380s sys 0m14.927s ``` And after: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 88 nonvoluntary_ctxt_switches: 899 real 0m2.031s user 0m1.209s sys 0m0.743s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 75 nonvoluntary_ctxt_switches: 8 real 0m2.062s user 0m1.279s sys 0m0.783s ``` I was concerned these results might still be reflective of a bug in Thread::Queue, so I also came up with a repro that doesn't rely on it. That one is [[here]](https://gist.github.com/jpl-coconut/aa14e59354abf98f808daaf39baa9a72). Results summary: - Single-core performance improves (this time by only 30%) - Multi-core penalty drops from 4x to 0. - No change to context-switching rates. - system_time/user_time ratio drops from (0.5-1) to 0.15 Before fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.336s user 0m0.211s sys 0m0.118s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m1.424s user 0m0.468s sys 0m0.496s ``` After fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 59 real 0m0.241s user 0m0.202s sys 0m0.032s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.238s user 0m0.195s sys 0m0.035s ``` -- https://bugs.ruby-lang.org/

7 18

[ruby-core:125071] [Ruby Feature#21957] Introduce `Enumerable#close` to free internal resources.
by ioquatix (Samuel Williams) 02 Jul '26

02 Jul '26

Issue #21957 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #21957: Introduce `Enumerable#close` to free internal resources. https://bugs.ruby-lang.org/issues/21957 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- In some cases, `Enumerable` has substantial internal state (e.g. Fiber) related to enumeration. There is currently no way to clear up this state besides garbage collection, which means that we can accumulate considerable garbage before cleaning up, even if we know when the enumerable is no longer needed. I'd like to introduce `Enumerable#close` which invalidates the enumerable, freeing internal resources. After which, most usage would result in `Enumerable::ClosedError`. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:115879] [Ruby master Bug#20081] Transfered Fiber doesn't return to Fiber that started it
by rmosolgo (Robert Mosolgo) 01 Jul '26

01 Jul '26

Issue #20081 has been reported by rmosolgo (Robert Mosolgo). ---------------------------------------- Bug #20081: Transfered Fiber doesn't return to Fiber that started it https://bugs.ruby-lang.org/issues/20081 * Author: rmosolgo (Robert Mosolgo) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin22] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Hi! I'm trying to figure out how to make sure that Fibers started with `.transfer` end up _terminated_, not just suspended. (If they're suspended, Rails thinks they're still alive, and they continue to hold onto database connections, see: https://github.com/rmosolgo/graphql-ruby/issues/4739#issuecomment-1866930914.) So, I'm looking for way to make sure that any Fiber I start with `.transfer` will be properly terminated. But what I noticed is that when a transfer-based Fiber terminates, it gives control back to the top-most Fiber, not the Fiber which transfered to it. Is this intended? Here's a script to replicate the issue: ```ruby manager = Fiber.new do parent = Fiber.current worker = Fiber.new do puts "2. Begin Worker" parent.transfer puts "4. End Worker" end puts "1. Transfer 1" worker.transfer puts "3. Transfer 2" worker.transfer puts "5. Finished manager" end manager.transfer puts "6. Finished script" ``` I expect the steps to print in order: ``` 1. Transfer 1 2. Begin Worker 3. Transfer 2 4. End Worker 5. Finished manager 6. Finished script ``` But instead, `5. ...` is skipped: ``` 1. Transfer 1 2. Begin Worker 3. Transfer 2 4. End Worker 6. Finished script ``` I think that's because my `worker` fiber terminates and passes control back to the top-level Fiber. Should it have passed control back to the `manager`? Or is there another way to make sure `worker` is terminated, and `manager` gets control? -- https://bugs.ruby-lang.org/

3 9

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

30 Jun '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 4