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

[ruby-core:117027] [Ruby master Bug#20319] Singleton class is being frozen lazily in some cases
by andrykonchin (Andrew Konchin) 24 Feb '26

24 Feb '26

Issue #20319 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #20319: Singleton class is being frozen lazily in some cases https://bugs.ruby-lang.org/issues/20319 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I've noticed suspicious behaviour (it doesn't affect anything in practice for me though) when an object becomes frozen only its own singleton class becomes frozen immediately. A singleton class of the immediate singleton class becomes frozen lazily after `#singleton_class` method call: ```ruby o = Object.new klass = o.singleton_class.singleton_class o.freeze puts klass.frozen? # false <== here we expect true puts o.singleton_class.singleton_class.frozen? # true puts klass.frozen? # true ``` I would expect all created singleton classes in an object singleton classes chain to become frozen immediately. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:124869] [Ruby Feature#21923] DTrace USDT probe Ruby method arguments and return value
by jacobcarlborg (Jacob Carlborg) 23 Feb '26

23 Feb '26

Issue #21923 has been reported by jacobcarlborg (Jacob Carlborg). ---------------------------------------- Feature #21923: DTrace USDT probe Ruby method arguments and return value https://bugs.ruby-lang.org/issues/21923 * Author: jacobcarlborg (Jacob Carlborg) * Status: Open ---------------------------------------- I'm interested in improving the DTrace USDT probes in Ruby. I would like to expose the Ruby method arguments and return value to the DTrace probes `(c)method-entry` and `(c)method-return`. This would be done by adding a fifth argument to the DTrace probes. For `method-entry` this would be the Ruby arguments the Ruby method is called with and for `method-return` it would be the Ruby return value the Ruby method returned. My idea is to serialize the arguments as a JSON array and pass that as a C string, containing the JSON data, to the USDT probes. On the DTrace side, there's a `json` function available that can be used to extract parts of the JSON structure using a simple query string, example: `json(copyinstr(arg4), "success.foo.bar[1].baz")`. Because the serialization can fail, the top level JSON member would be `success` or `error` indicating if the serialization was successful or not. Using JSON to pass data to a DTrace USDT probe has precedence in the form of a Rust crate [1], created by one of the original DTrace authors, that uses the same approach. I have a proof of concept implementing this. I would like to get some feedback on how to best implement this. I think the main challenge is how to implement this without any side effects. Ruby already has support for serializing to JSON, but that is implemented in a separate gem, using a C extension. The challenges I see are: * There shouldn't be any side effects when enabling DTrace probes, therefore directly using the gem is not a good alternative. It needs to load a dynamic library and new constants will become available to the Ruby code, if this gem is used. * The JSON serialization for DTrace needs to live in the Ruby VM and not in a separate gem. The question is then: should the JSON serialization for the gem and the DTrace probes be shared? Alternatively there could be an implementation of JSON serialization, for the gem, and a DTrace probe argument serialization, that happens to use JSON, but would be an implementation detail. * If the JSON serialization should be shared between DTrace probes and the gem, is there a mechanism to share code between the Ruby VM and a gem without publicly exposing it, i.e. to C extensions? Or would there need to be an official JSON API that other C extensions could use? * The current JSON implementation relies on exceptions. For DTrace, it would be better not to rely on exceptions. But I guess it would be possible to catch all exceptions. * The current JSON implementation will, except for the `JSON` class, expose some additional constants which should not happen when using DTrace. This will introduce side effects. This should be possible to handle by slightly modifying the implementation. * The current JSON serialization supports customizing the serialization by implementing the `to_json`/`as_json` methods. If serializing DTrace arguments with support for the `to_json`/`as_json` methods, the advantage is that this is already implemented by some third-party libraries. The disadvantage is that it could cause side effects. * When DTrace probes are enabled and serializing the DTrace probe arguments and some Ruby methods are called, it would be best if those weren't traced. Can a global variable be used to check if the Ruby VM already is currently serializing DTrace probe arguments? Or is an atomic or thread-local variable necessary? Or is there a better alternative to do this? [1] https://github.com/oxidecomputer/usdt -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124868] [Ruby Feature#19107] Allow trailing comma in method signature
by Earlopain (Earlopain _) 23 Feb '26

23 Feb '26

Issue #19107 has been updated by Earlopain (Earlopain _). > What about the lambda arguments? @nobu it's unclear to me so I didn't change them. I added https://bugs.ruby-lang.org/issues/21875 to the next dev meeting. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116524 * Author: byroot (Jean Boussier) * Status: Closed * Assignee: core ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124867] [Ruby Feature#19107] Allow trailing comma in method signature
by nobu (Nobuyoshi Nakada) 23 Feb '26

23 Feb '26

Issue #19107 has been updated by nobu (Nobuyoshi Nakada). Assignee changed from prism to core What about the lambda arguments? commit:731b6092e9268af960bf0f060e37504f4deb7380 seems not to allow `->(a,) {}`. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116523 * Author: byroot (Jean Boussier) * Status: Closed * Assignee: core ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124854] [Ruby Bug#21919] `libruby-static.a` links to wrong `Init_enc`
by reitermarkus (Markus Reiter) 22 Feb '26

22 Feb '26

Issue #21919 has been reported by reitermarkus (Markus Reiter). ---------------------------------------- Bug #21919: `libruby-static.a` links to wrong `Init_enc` https://bugs.ruby-lang.org/issues/21919 * Author: reitermarkus (Markus Reiter) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin20] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When building Ruby with `--with-static-linked-ext`, `libruby-static.a` links the `Init_enc` function from `dmyenc.c` instead of `enc/encinit.c.erb`, resulting in `uninitialized constant Encoding::UTF_8` error, among other things. There seems to be a discrepancy between `INITOBJS` (https://github.com/ruby/ruby/blob/e730ac41be4d427f06540e0f67fa16bbdced4789/…) and `ENCOBJS`/`EXTOBJS` (https://github.com/ruby/ruby/blob/e730ac41be4d427f06540e0f67fa16bbdced4789/…) Currently, the only workaround I found is to manually link `enc/libenc.a` and `enc/libtrans.a` to the final binary. Originally reported here: https://github.com/matsadler/magnus/issues/169 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124861] [Ruby Feature#17056] Array#index: Allow specifying the position to start search as in String#index
by Earlopain (Earlopain _) 21 Feb '26

21 Feb '26

Issue #17056 has been updated by Earlopain (Earlopain _). I often use the offset parameter from `String#byteindex` and was a bit surprised there is not yet something for arrays. It's a bit unfortunate with the ambiguity between block/noblock usage but a keyword argument `offset` seems like a perfectly fine solution for that. ---------------------------------------- Feature #17056: Array#index: Allow specifying the position to start search as in String#index https://bugs.ruby-lang.org/issues/17056#change-116515 * Author: TylerRick (Tyler Rick) * Status: Open ---------------------------------------- I have a use case of finding the first matching line within a given section in a file. After finding the line number of the start of the section, I want to find the first match after that line. My workaround for now is to use `with_index`: ```ruby lines = pathname.read.lines section_start_line = lines.index {|line| line.start_with?(/#* #{section_name}/) } lines.index.with_index {|line, i| i > section_start_line && line.include?(sought) } ``` I'd like to do it in a more concise way using a feature of `Array#index` that I propose here, which is analogous to `String#index`. If the second parameter of `String#index` is present, it specifies the position in the string to begin the search: ```ruby 'abcabc'.index('a') # => 0 'abcabc'.index('a',2) # => 3 ``` I would expect to also be able to do: ```ruby 'abcabc'.chars.index('a') # => 0 'abcabc'.chars.index('a', 2) ``` Using such feature, I would be able to do: ```ruby lines.index(sought, section_start_line) ``` This would give Ruby better parity with other programming languages like Python: ```python >>> list('abcabc') ['a', 'b', 'c', 'a', 'b', 'c'] >>> list('abcabc').index('a') 0 >>> list('abcabc').index('a', 2) 3 ``` ## End index We can further think of an optional parameter to specify the position to end the search. The following languages allow specifying both start and end indexes: - [Python](https://docs.python.org/3/tutorial/datastructures.html) - [C#](https://docs.microsoft.com/en-us/dotnet/api/system.array.indexof?view=n… Ruby's `String#index` does not have one, so we could make a separate proposal to add `end` to both methods at the same time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124855] [Ruby Bug#21920] LIBRUBYARG_SHARED contains -lgmp and other libraries for static linking
by larskanis (Lars Kanis) 21 Feb '26

21 Feb '26

Issue #21920 has been reported by larskanis (Lars Kanis). ---------------------------------------- Bug #21920: LIBRUBYARG_SHARED contains -lgmp and other libraries for static linking https://bugs.ruby-lang.org/issues/21920 * Author: larskanis (Lars Kanis) * Status: Open * ruby -v: ruby 4.1.0dev (2026-02-21 master e730ac41be) +PRISM [aarch64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- That recent commit introduced `MAINLIBS` into `LIBRUBYARG_SHARED`: https://github.com/ruby/ruby/commit/d256629bf9e194838d1837be74dcc0b8ff0bcfd6 Before that commit: ``` CONFIG["LIBRUBYARG_SHARED"] = "-l$(RUBY_SO_NAME)" CONFIG["LIBRUBYARG_STATIC"] = "-l$(RUBY_SO_NAME)-static $(MAINLIBS)" RbConfig::CONFIG["LIBRUBYARG_SHARED"] # => "-laarch64-ucrt-ruby410" ``` After that commit: ``` CONFIG["LIBRUBYARG_SHARED"] = "-l$(RUBY_SO_NAME) $(MAINLIBS)" CONFIG["LIBRUBYARG_STATIC"] = "-l$(RUBY_SO_NAME)-static $(MAINLIBS)" RbConfig::CONFIG["LIBRUBYARG_SHARED"] # => "-laarch64-ucrt-ruby410 -lgmp -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi -lbcrypt" ``` To my understanding `MAINLIBS` are only for static linking and these libraries are not necessary for shared linking. This breaks RubyInstaller for Windows, since all C extensions are linked with `LIBRUBYARG_SHARED` and the RubyInstaller distribution ships `libgmp-10.dll` only but not related the `libgmp.a` file. The same happens on x86_64. It is probably an issue on other operating systems as well. A CI failure log is here: https://github.com/oneclick/rubyinstaller2/actions/runs/22238372563/job/643… -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124646] [Ruby Bug#21855] Bundle `win32-registry` or implement it without `fiddle`
by Earlopain (Earlopain _) 20 Feb '26

20 Feb '26

Issue #21855 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21855: Bundle `win32-registry` or implement it without `fiddle` https://bugs.ruby-lang.org/issues/21855 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `win32-registry` (a default gem), is currently implemented via `fiddle` (a bundled gem). This makes it impossible to use under bundler without adding `fiddle` to the gemfile. In the past it has lead to issues like https://bugs.ruby-lang.org/issues/21645. It was solved by simply not using `win32-registry` anymore in `resolv` and implementing it via C (https://github.com/ruby/resolv/pull/110) although the overarching issue is still present. There is also a report for this for rubygems https://github.com/ruby/rubygems/issues/9277. This should be solved by updating the vendored `resolv` version I think. Still, the dependecy relation between `win32-registry` and `fiddle` is pretty incompatible. A default gem can't depend on a bundled gem without breaking dependency resolution. To solve this it would have to be implemented without using `fiddle`, similar to how `resolv` did it. But now that `resolv` doesn't use `win32-registry`, I don't think anything in ruby uses it anymore. So moving it to a bundled gem could also be a solution without rewriting the whole thing. Here is an issue about this in the `win32-registry` repo: https://github.com/ruby/win32-registry/issues/11 -- https://bugs.ruby-lang.org/

3 5

[ruby-core:124848] [Ruby Bug#21917] Unable to build 4.0.1 on AIX 7.2
by mhashizume (Michael Hashizume) 19 Feb '26

19 Feb '26

Issue #21917 has been reported by mhashizume (Michael Hashizume). ---------------------------------------- Bug #21917: Unable to build 4.0.1 on AIX 7.2 https://bugs.ruby-lang.org/issues/21917 * Author: mhashizume (Michael Hashizume) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I'm attempting to build Ruby 4.0.1 on AIX 7.2. We have had successful builds of previous versions of Ruby on this platform, but are starting to see an issue when using miniruby to build Ruby: ``` shell ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems -r./powerpc64-aix7.2.0.0-fake ./tool/rbinstall.rb --make="gmake" --dest-dir="" --extout=".ext" --ext-build-dir="./ext" --mflags="-j3 --jobserver-auth=fifo:/tmp//GMfifo9306586" --make-flags=" -j3 --jobserver-auth=fifo:/tmp//GMfifo9306586" --data-mode=0644 --prog-mode=0755 --installed-list .installed.list --mantype="man" --install=all --exclude=doc /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in 'Kernel#require': false() function is unimplemented on this machine (NotImplementedError) from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in 'Kernel#eval' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from ./tool/rbinstall.rb:25:in 'Kernel#require' from ./tool/rbinstall.rb:25:in '<main>' ``` I'm not sure where the NotImplementedError is coming from, and when looking at the `truss` output from miniruby, I see a ENOTTY when miniruby attempts to load monitor.so: ```shell accessx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0, 0) = 0 statx("/", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0", 0x0FFFFFFFFFFFA680, 176, 011) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0x0FFFFFFFFFFFA680, 176, 011) = 0 __ksetjmp(0x0000000110019F88, 0x09000000026845A8, 2, 0x000000011001A1D8, 0x0FFFFFFFFFFFB790, 0x0000000022242202, 0x000000011011A658, 0x09000 00000260348) = 0 statx("/var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/powerpc64-aix7.2.0.0/monitor.so", 0x0FFFFFFFFFFFB800, 176, 0) = 0 kioctl(2, 22528, 0x0000000000000000, 0x0000000000000000) Err#25 ENOTTY /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in 'Kernel#require': false() function is unimplemented on this machine (NotImpl ementedError) from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/.ext/common/monitor.rb:10:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in 'Kernel#eval' from /var/tmp/tmp.INfzUXAeGi/ruby-4.0.1/lib/rubygems.rb:1452:in '<top (required)>' from ./tool/rbinstall.rb:25:in 'Kernel#require' from ./tool/rbinstall.rb:25:in '<main>' ``` monitor.so is present in the path that miniruby is looking for it. Any pointers on where to start debugging this further or what changes in more recent versions of Ruby could have caused this would be greatly appreciated. Thank you! -- https://bugs.ruby-lang.org/

2 3

[ruby-core:124851] [Ruby Bug#21918] fiber scheduler: fiber interrupt triggers for IOs that haven't been closed
by chucke (Tiago Cardoso) 19 Feb '26

19 Feb '26

Issue #21918 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #21918: fiber scheduler: fiber interrupt triggers for IOs that haven't been closed https://bugs.ruby-lang.org/issues/21918 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've been chasing an issue, which I believe is to with the recent introduction of the `fiber_interrupt` hook in ruby 4. As a reproduction I have the following snippet: ```ruby require "socket" require_relative "test/fiber/scheduler" # use the one defined here: https://github.com/ruby/ruby/blob/master/test/fiber/scheduler.rb udp = UDPSocket.new(Socket::AF_INET) tcp = Socket.new(Socket::AF_INET, :STREAM, 0) tcp.connect(Socket.sockaddr_in(80, "nghttp2")) t = Thread.start do Thread.current.abort_on_exception = true scheduler = Scheduler.new Fiber.set_scheduler scheduler 5.times do Fiber.schedule do begin puts "#{Fiber.current.object_id} -> wait udp" udp.to_io.wait_readable(2) rescue IOError => e puts "#{Fiber.current.object_id} -> udp io error: #{e}" end begin puts "#{Fiber.current.object_id} -> closing udp" udp.close puts "#{Fiber.current.object_id} -> closed udp" puts "#{Fiber.current.object_id} -> wait tcp" tcp.to_io.wait_readable(2) puts "#{Fiber.current.object_id} -> done" rescue => e puts "#{Fiber.current.object_id} -> tcp io error: #{e}" else puts "#{Fiber.current.object_id} -> closing tcp" tcp.close end end end end t.join ``` This produces the following output to me: ``` 1472 -> wait udp 1488 -> wait udp 1496 -> wait udp 1504 -> wait udp 1512 -> wait udp 1472 -> closing udp 1488 -> closing udp 1488 -> closed udp 1488 -> wait tcp 1496 -> closing udp 1496 -> closed udp 1496 -> wait tcp 1504 -> closing udp 1504 -> closed udp 1504 -> wait tcp 1512 -> closing udp 1512 -> closed udp 1512 -> wait tcp 1512 -> tcp io error: stream closed in another thread 1504 -> tcp io error: stream closed in another thread 1496 -> tcp io error: stream closed in another thread 1488 -> tcp io error: stream closed in another thread 1472 -> closed udp 1472 -> wait tcp 1472 -> done 1472 -> closing tcp ``` The thing that makes this program very confusing is that the "stream closed in another thread" related to the udp socket is raised while waiting for read readiness on the tcp socket. In such a situation, I'd expect the error to relate to the actual socket being waited on, not something else that fiber does not care about anymore. One thing that could have helped would be to have the reference of which IO object the exception relates to in the exception (aka `IOError#io` would return the socket). Nevertheless, I'd still consider an issue that this triggers in the wrong "fiber.yield" moment. Therefore, I think there are two possible outcomes here: 1. all fibers stop on `udp.close` until it is in fact closed (and then IOError is raised before the "closed udp" message can be printed) 2. exceptions related to IOs not actively being monitored by the current fiber are ignored. -- https://bugs.ruby-lang.org/

1 0