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

[ruby-core:126887] [Ruby Misc#22394] DevMeeting-2026-10-07
by hsbt (Hiroshi SHIBATA) 05 Oct '26

05 Oct '26

Issue #22394 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Misc #22394: DevMeeting-2026-10-07 https://bugs.ruby-lang.org/issues/22394 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/10/07 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2026/10/04. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

6 7

[ruby-core:126927] [Ruby Bug#22407] IO::Buffer#set_value does not call to_int for 128-bit values
by hanazuki (Kasumi Hanazuki) 05 Oct '26

05 Oct '26

Issue #22407 has been reported by hanazuki (Kasumi Hanazuki). ---------------------------------------- Bug #22407: IO::Buffer#set_value does not call to_int for 128-bit values https://bugs.ruby-lang.org/issues/22407 * Author: hanazuki (Kasumi Hanazuki) * Status: Open * ruby -v: ruby 4.1.0dev (2026-10-05T15:26:55Z master 2c1e694a53) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- IO::Buffer gained support for reading and writing 128-bit integers (:u128, :U128, :s128, and :S128) in Ruby 4.0 (commit:a7dc53b91c8475323b34d5a332fdb25d190e277d). Unlike the other smaller integer types, IO::Buffer#set_value does not call to_int on non-Integer values for the 128-bit types. Same for #set_values. ```ruby IntegerLike = Data.define(:value) do def to_int = value end buf = IO::Buffer.new(16) buf.set_value(:u64, 0, IntegerLike.new(42)) buf.set_value(:u128, 0, IntegerLike.new(42)) # => not an integer (TypeError) ``` Hence the 128-bit integer types do not satisfy this statement in the method's documentation: > Note that if the type is integer and value is Float, the implicit truncation is performed -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126922] [Ruby Feature#11817] map.parallel
by Mordeccai (Martin Wein) 04 Oct '26

04 Oct '26

Issue #11817 has been updated by Mordeccai (Martin Wein). I’d like to revive this proposal with a concrete use case I ran into in a Rails application. I frequently need to perform the same I/O-bound operation concurrently over a collection — for example, generating multiple documents through an external API — wait until all operations complete, and collect the results in order. In JavaScript this is straightforward: <pre> await Promise.all(items.map(process)) </pre> In Ruby, this still generally requires a gem and additional machinery. I think Ruby would benefit from a simple standard abstraction such as: <pre> items.concurrently { process(it) } </pre> or: <pre> items.concurrent_map { process(it) } </pre> The implementation could use a bounded concurrency mechanism rather than creating one thread per item. Nearly 11 years after this issue was opened, has Ruby’s concurrency model evolved enough that something like this could now be reconsidered? ---------------------------------------- Feature #11817: map.parallel https://bugs.ruby-lang.org/issues/11817#change-119305 * Author: eike.rb (Eike Dierks) * Status: Open ---------------------------------------- I'd like to suggest a new method: #parallel That method should take care of executing workloads in parallel across multiple cores. I believe that #map can sometimes be distributed to many simultaneous threads. So we would spread out the map blocks into parallel processing, and then collect the results in order. I believe this would need some new infrastructure like apple did with great_central, so I'm talking along these lines. (Aka we only want to open up as many threads as there are cores) This would not help much with a simple map (because we need to collect and serialize the results in the end) but it could be cool for more complex mappings. Maybe this should have been a rails topic first, because there it might make a lot of sense to render partials in parallel, this could really speed up rails response rendering ;-) But I believe this is a topic for ruby in general. Given that we now go to really many cores, it should be at the heart of ruby to use that. For a start we could just declare #parallel as -> return self. and than improve on it. A naive implementation would just open a new thread for every parallel map block, but that would not work well -- it actually would be very slow. So we actually need a thread management, along the lines of great central. I believe this should be built into the very core libs of the ruby language. I know this is hard stuff, but it needs to be done. Let's go parallel from the heart of the language. --- Please let us discuss if adding the #parallel method would be a good idea. Let's come up with some implementations to find the problems. I'm explicitly referring to map#parallel here. In rails that might be cache.parallel (if you followed) for some math tasks it might also be parallel do {} -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126747] [Ruby Bug#22327] RubyVM::ZJIT.reset_stats! aborts the process (Rust panic) when ZJIT is not enabled
by znz (Kazuhiro NISHIYAMA) 04 Oct '26

04 Oct '26

Issue #22327 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #22327: RubyVM::ZJIT.reset_stats! aborts the process (Rust panic) when ZJIT is not enabled https://bugs.ruby-lang.org/issues/22327 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Assignee: jit * ruby -v: ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [x86_64-linux] * Backport: 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- `RubyVM::ZJIT.reset_stats!` aborts the whole process with a Rust panic when it is called while ZJIT is not enabled. The other stats methods (`stats`, `stats_string`, `stats_enabled?`) just return `nil`/`false` in the same situation, and `RubyVM::YJIT.reset_stats!` returns `nil` when YJIT is disabled, so I think `reset_stats!` should also be a no-op instead of crashing. ## Reproduction ``` $ ruby -e 'p RubyVM::ZJIT.enabled?; RubyVM::ZJIT.reset_stats!; puts "after"' false thread '<unnamed>' (1) panicked at /usr/src/ruby/zjit/src/state.rs:200:13: ZJITState::get_instance called when ZJIT is not enabled note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread '<unnamed>' (1) panicked at .../library/core/src/panicking.rs:225:5: panic in a function that cannot unwind (backtrace and bug report dump follow) Aborted (core dumped) $ echo $? 134 ``` Expected: `after` is printed and the process exits with 0 (`reset_stats!` returns `nil`, as it does when ZJIT is enabled). Reproduced with: - ruby 4.1.0dev (2026-09-15T06:59:41Z master 0c3c61ca82) +PRISM [x86_64-linux] (`ghcr.io/ruby/ruby:master`; panic at `zjit/src/state.rs:200`) - ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [x86_64-linux] (`ghcr.io/ruby/ruby:4.0.7`; panic at `zjit/src/state.rs:168`) For comparison, these do not crash: ``` $ ruby -e 'p RubyVM::ZJIT.stats, RubyVM::ZJIT.stats_string, RubyVM::ZJIT.stats_enabled?' nil nil false $ ruby -e 'p RubyVM::YJIT.enabled?, RubyVM::YJIT.reset_stats!' false nil $ ruby --zjit -e 'p RubyVM::ZJIT.enabled?, RubyVM::ZJIT.reset_stats!' true nil ``` ## Cause `rb_zjit_reset_stats_bang` in `zjit/src/stats.rs` calls `ZJITState::get_counters()` etc. unconditionally, and `ZJITState::get_instance` panics when the state has not been initialized. `rb_zjit_stats` in the same file starts with `if !zjit_enabled_p() { return Qnil; }`; adding the same guard to `rb_zjit_reset_stats_bang` would fix this. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126918] [Ruby Bug#22403] Ruby::Box: a class that gets a box-specific classext is never freed
by shluboto (Andreas Busold) 04 Oct '26

04 Oct '26

Issue #22403 has been reported by shluboto (Andreas Busold). ---------------------------------------- Bug #22403: Ruby::Box: a class that gets a box-specific classext is never freed https://bugs.ruby-lang.org/issues/22403 * Author: shluboto (Andreas Busold) * Status: Open * ruby -v: ruby 4.1.0dev (2026-10-04T10:47:58Z master 76aa225e9a) +PRISM [x86_64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- With `RUBY_BOX=1`, a class that receives a box-specific classext is never freed while its box lives, and for the main box that is the life of the process. Freezing the clone of a frozen object that extends a module creates one such class per call, so a program that does this per request grows without bound. No user box is needed: setting the environment variable is enough. ```ruby base = Object.new.extend(Module.new).freeze GC.start before = ObjectSpace.count_objects[:T_CLASS] 5_000.times { base.clone.freeze } GC.start p ObjectSpace.count_objects[:T_CLASS] - before ``` ``` $ ruby repro.rb 0 $ RUBY_BOX=1 ruby repro.rb 5000 ``` Expected: about 0 with `RUBY_BOX=1` as well. The clones and their singleton classes are unreachable after the loop, and without the flag Ruby frees them. The load-bearing parts: `base` has a singleton class (from `extend`) and is frozen, and the clone is frozen again. `base.clone`, `Object.new.extend(M).clone`, or freezing an object with a fresh singleton class leak nothing. What the source shows (read, not traced at runtime): - `rb_class_set_box_classext` (`class.c`) inserts the class into `box->classext_cow_classes`. - `rb_box_entry_mark` (`box.c`) marks that table with `rb_mark_set`, so every class in it is reachable. - Entries leave the table only in `rb_class_unlink_classext`, which runs when the box is freed (`free_classext_for_box`). Not traced: which call inside `freeze` gives the clone's singleton class its box-specific classext; Bug #20319 (singleton classes frozen lazily) may be that path. Bug #22339 concerns the same table at VM shutdown. A weak reference from the table to the class, dropping the entry when the class is freed, would keep the copy-on-write bookkeeping without holding the class. Impact: Sequel before 5.67 cloned a frozen, extended dataset on every model query, and a Rails server with `RUBY_BOX=1` grew from 342 MB to 505 MB over 2,400 requests (flat at 150 MB without the flag). Also reproduced on ruby 4.0.7 (2026-09-15 revision 229531a6cf) +PRISM [x86_64-darwin25] (5000 against 1), and on x86_64-linux 4.0.7 with the same shape written as `clone(freeze: false).freeze`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126916] [Ruby Bug#22257] Prepending a module to an already-included module leaves stale super caches
by nagachika (Tomoyuki Chikanaga) 04 Oct '26

04 Oct '26

Issue #22257 has been updated by nagachika (Tomoyuki Chikanaga). I don't know why there's a inconsistency, but the corresponding commit hash in master branch was git:c59c4d717a2e687972341eab1574196e97d7d7be. ---------------------------------------- Bug #22257: Prepending a module to an already-included module leaves stale super caches https://bugs.ruby-lang.org/issues/22257#change-119299 * Author: eightbitraptor (Matt V-H) * Status: Closed * Target version: 4.1 * Backport: 3.3: WONTFIX, 3.4: DONE, 4.0: DONE ---------------------------------------- When a module is prepended to a module that already has includers, super call sites inside the prepended module keep calling the old method entry after the method is redefined. [**Fix implemented in this PR**](https://github.com/ruby/ruby/pull/18421) <pre> module M; def foo; :m; end; end class D; include M; end M.prepend(Module.new { def foo; super; end }) D.new.foo # prime the super call-site cache M.send(:define_method, :foo) { :hooked } p D.new.foo </pre> I found this while working on an unrelated Ractor issue. But this problem manifests itself for Ractors as follows: <pre> Ractor.new {} require 'set' Kernel.send(:define_method, :require) { |f| $hook = f } require 'set' p $hook # => nil, the hook never runs </pre> This is because creating the first Ractor prepends an internal `RactorRequire` wrapper onto Kernel. After the first require primes the cache in the wrapper, redefining Kernel#require silently does nothing. The linked PR fixes this by registering the backfilled iclass in the module's subclasses list, after the includer walk finishes. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126915] [Ruby Bug#22257] Prepending a module to an already-included module leaves stale super caches
by nagachika (Tomoyuki Chikanaga) 04 Oct '26

04 Oct '26

Issue #22257 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 3.3: WONTFIX, 3.4: REQUIRED, 4.0: DONE to 3.3: WONTFIX, 3.4: DONE, 4.0: DONE merged into ruby_3_4 at https://github.com/ruby/ruby/commit/c8e05b5885dbfb306528c73be5de2f63b297bbd3. ---------------------------------------- Bug #22257: Prepending a module to an already-included module leaves stale super caches https://bugs.ruby-lang.org/issues/22257#change-119298 * Author: eightbitraptor (Matt V-H) * Status: Closed * Target version: 4.1 * Backport: 3.3: WONTFIX, 3.4: DONE, 4.0: DONE ---------------------------------------- When a module is prepended to a module that already has includers, super call sites inside the prepended module keep calling the old method entry after the method is redefined. [**Fix implemented in this PR**](https://github.com/ruby/ruby/pull/18421) <pre> module M; def foo; :m; end; end class D; include M; end M.prepend(Module.new { def foo; super; end }) D.new.foo # prime the super call-site cache M.send(:define_method, :foo) { :hooked } p D.new.foo </pre> I found this while working on an unrelated Ractor issue. But this problem manifests itself for Ractors as follows: <pre> Ractor.new {} require 'set' Kernel.send(:define_method, :require) { |f| $hook = f } require 'set' p $hook # => nil, the hook never runs </pre> This is because creating the first Ractor prepends an internal `RactorRequire` wrapper onto Kernel. After the first require primes the cache in the wrapper, redefining Kernel#require silently does nothing. The linked PR fixes this by registering the backfilled iclass in the module's subclasses list, after the includer walk finishes. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126523] [Ruby Misc#22272] Propose Kevin Menard (@nirvdrum) as a core committer
by tekknolagi (Maxwell Bernstein) 02 Oct '26

02 Oct '26

Issue #22272 has been reported by tekknolagi (Maxwell Bernstein). ---------------------------------------- Misc #22272: Propose Kevin Menard (@nirvdrum) as a core committer https://bugs.ruby-lang.org/issues/22272 * Author: tekknolagi (Maxwell Bernstein) * Status: Open * Assignee: core ---------------------------------------- ## Proposal I'd like to propose Kevin Menard (@nirvdrum) as a committer. He started full-time work on ZJIT about a year ago and has been doing excellent work since. For example, he wrote the function inliner, which is the single biggest lever a method-based compiler can have when trying to optimize code. He has years of compiler experience and additionally years of Ruby experience from working on TruffleRuby and CRuby. Especially since he has been contributing to Ruby for years now and knows the community, I think he should be able to merge his own changes. Here is Kevin's message: ## Kevin Menard's Message I've been active in the Ruby community since 2008. I started contributing performance improvements to Psych in 2012. I began contributing to CRuby in 2015 by diving into strings and reporting code range bugs. Since then I've contributed to the interpreter, YJIT, Prism, the Ruby Spec Suite, and several other Ruby org projects. I've been working extensively on ZJIT for the past nine months. A sample of my contributions include: * **ZJIT:** * Added method inlining to ZJIT ([ruby/ruby#16966](https://github.com/ruby/ruby/pull/16966)) * Optimized `super` calls to C functions in ZJIT ([ruby/ruby#15993](https://github.com/ruby/ruby/pull/15993/changes)) * **YJIT**: * Added a compilation log to YJIT ([ruby/ruby#11818](https://github.com/ruby/ruby/pull/11818)) * Optimized byte appends via `String#<<` ([ruby/ruby#11032](https://github.com/ruby/ruby/pull/11032)) * **Interpreter**: * Cheaply derive the code range for `String#b` ([ruby/ruby#6183](https://github.com/ruby/ruby/pull/6183)) * Optimized byte appends via `String#<<` ([ruby/ruby#10968](https://github.com/ruby/ruby/pull/10968)) * **Prism:** * Set `Regexp` encoding flags ([ruby/prism#2486](https://github.com/ruby/prism/pull/2486)) * Track `Symbol` encoding changes from source encoding ([ruby/prism#2268](https://github.com/ruby/prism/pull/2268)) Being a committer would make it much easier for me to contribute to ZJIT and keep up with its rapid pace of development. -- https://bugs.ruby-lang.org/

11 11

[ruby-core:114332] [Ruby master Bug#19794] Ruby 3.2.2 fails to build on macOS Sonoma betas
by jhaungs (Jim Haungs) 02 Oct '26

02 Oct '26

Issue #19794 has been reported by jhaungs (Jim Haungs). ---------------------------------------- Bug #19794: Ruby 3.2.2 fails to build on macOS Sonoma betas https://bugs.ruby-lang.org/issues/19794 * Author: jhaungs (Jim Haungs) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- With Big Sur, Apple deprecated putting dylibs in /usr/local/lib. In Sonoma (beta 4), this directory has disappeared completely. However, ruby's configure script depends on its existence. So, virtually every ruby installer (RVM, rbenv, asdf, ruby-build, and even building from source tarball) fails. When building ruby 3.2.2 from source, the configure step outputs the irritatingly useless "something wrong with LDFLAGS" error message and fails to build. The solution was to `cd /usr/local; sudo mkdir lib` to create the missing lib directory under /usr/local. It would be nice to remove this dependency from the configure script. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:126905] [Ruby Bug#22401] addr2line.c does not build when crt_externs.h is absent (iOS SDK)
by albertus (Dominik Alberski) 01 Oct '26

01 Oct '26

Issue #22401 has been reported by albertus (Dominik Alberski). ---------------------------------------- Bug #22401: addr2line.c does not build when crt_externs.h is absent (iOS SDK) https://bugs.ruby-lang.org/issues/22401 * Author: albertus (Dominik Alberski) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby version: master (4.0.7) addr2line.c includes <crt_externs.h> unconditionally. The build fails on Darwin targets where that header is absent. The public iOS SDK does not ship crt_externs.h. ## Steps to reproduce Configure Ruby for a Darwin target without crt_externs.h, then run make. One example is a cross-compile for armv7-apple-ios6.0 against the iOS 6.1 SDK: ``` SDK=/path/to/iPhoneOS6.1.sdk CC="clang -target armv7-apple-ios6.0 -isysroot $SDK" \ CPP="clang -target armv7-apple-ios6.0 -isysroot $SDK -E" \ ../ruby/configure --host=armv7-apple-darwin10 --build=aarch64-apple-darwin25 make ``` ## Actual result ``` addr2line.c:84:11: fatal error: 'crt_externs.h' file not found 1 error generated. ``` ## Expected result addr2line.c compiles. ## Cause Three other files already handle this case: hash.c, eval_intern.h and missing/setproctitle.c. They check HAVE_CRT_EXTERNS_H. When the header is absent, they include missing/crt_externs.h instead. configure.ac sets that macro for darwin targets. addr2line.c was missed. addr2line.c also calls _NSGetMachExecuteHeader(). Only the macOS crt_externs.h declares that function, so a fallback header alone is not sufficient. The fix must also declare the function locally, with the same __LP64__ distinction that crt_externs.h uses. The symbol itself exists in libSystem/dyld on iOS too. ## Proposed fix Branch: https://github.com/DominikAlberski/ruby/tree/fix/addr2line-crt-externs-fall… macOS behavior does not change. On macOS HAVE_CRT_EXTERNS_H is defined, so the includes and the declarations stay the same. I verified this by preprocessing both versions with HAVE_CRT_EXTERNS_H defined. The output is identical, apart from the __LINE__ numbers that the added lines shift. A test is not possible for this change. The code path is a compile-time header fallback, and macOS builds do not take it. -- https://bugs.ruby-lang.org/

1 0