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

[ruby-core:124408] [Ruby Bug#21816] iseq code_location miss calculated indent
by zzak (zzak _) 16 Jan '26

16 Jan '26

Issue #21816 has been reported by zzak (zzak _). ---------------------------------------- Bug #21816: iseq code_location miss calculated indent https://bugs.ruby-lang.org/issues/21816 * Author: zzak (zzak _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- TBH, I'm not really sure if that title matches the problem here, but I can produce this issue with the following test: ```ruby # bug.rb # note the indentation of the callable callable = -> { puts "Hello, World!" } iseq = RubyVM::InstructionSequence.of(callable) pp iseq.to_a pp iseq.to_a[4] pp iseq.to_a[4][:code_location][1] ``` Ruby 4.0.0: ``` $ ruby -v bug.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] ["YARVInstructionSequence/SimpleDataFormat", 4, 0, 1, {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 15, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism}, "block in <main>", "bug.rb", "/tmp/tmp.Fbq5WA0GnO/bug.rb", 1, :block, [], {}, [], [1, :RUBY_EVENT_LINE, :RUBY_EVENT_B_CALL, [:putself], [:putchilledstring, "Hello, World!"], [:opt_send_without_block, {mid: :puts, flag: 20, orig_argc: 1}], :RUBY_EVENT_B_RETURN, [:leave]]] {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 15, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism} 15 ``` Ruby 4.1.0: ``` $ ruby -v bug.rb ruby 4.1.0dev (2025-12-30T18:02:00Z master 9d37155cfc) +PRISM [x86_64-linux] ["YARVInstructionSequence/SimpleDataFormat", 4, 1, 1, {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 13, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism}, "block in <main>", "bug.rb", "/tmp/tmp.Fbq5WA0GnO/bug.rb", 1, :block, [], {}, [], [1, :RUBY_EVENT_LINE, :RUBY_EVENT_B_CALL, [:putself], [:putchilledstring, "Hello, World!"], [:opt_send_without_block, {mid: :puts, flag: 20, orig_argc: 1}], :RUBY_EVENT_B_RETURN, [:leave]]] {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 13, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism} 13 ``` For context: This second value being 13 instead of 15 is causing Rails tests to fail: https://buildkite.com/rails/rails-nightly/builds/3447#019b710f-e78a-405f-82… We want: ``` { @object.num } ``` But we get: ``` -> { @object.num } ``` I am pretty sure using the same version of `prism`: ``` /tmp/tmp.Fbq5WA0GnO => rbenv shell 4.1.0 /tmp/tmp.Fbq5WA0GnO => gem list | grep prism prism (1.7.0) /tmp/tmp.Fbq5WA0GnO => rbenv shell 4.0.0 /tmp/tmp.Fbq5WA0GnO => gem list | grep prism prism (1.7.0) ``` We use this data to get the original source string of a block we use to decorate the `assert_difference` assertion: https://github.com/rails/rails/blob/3d31d593e6cf0f82fa9bd0338b635af2f30d627… https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#m… -- https://bugs.ruby-lang.org/

4 5

[ruby-core:124054] [Ruby Misc#21768] Remove deprecated functions
by nobu (Nobuyoshi Nakada) 16 Jan '26

16 Jan '26

Issue #21768 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Misc #21768: Remove deprecated functions https://bugs.ruby-lang.org/issues/21768 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- -- https://bugs.ruby-lang.org/

4 3

[ruby-core:124047] [Ruby Feature#21766] Pathname + FileUtils making sweet music together
by gurgeous (Adam Doppelt) 16 Jan '26

16 Jan '26

Issue #21766 has been reported by gurgeous (Adam Doppelt). ---------------------------------------- Feature #21766: Pathname + FileUtils making sweet music together https://bugs.ruby-lang.org/issues/21766 * Author: gurgeous (Adam Doppelt) * Status: Open ---------------------------------------- I love Pathname. I love FileUtils. Let's bring these two classes EVEN CLOSER TOGETHER by adding some tragically missing helpers. Something like this, perhaps? ``` ruby class Pathname def mkdir_p(...) = FileUtils.mkdir_p(@path, ...) def ln(...) = FileUtils.ln(@path, ...) def ln_s(...) = FileUtils.ln_s(@path, ...) def ln_sf(...) = FileUtils.ln_sf(@path, ...) def cp(...) = FileUtils.cp(@path, ...) def cp_r(...) = FileUtils.cp_r(@path, ...) def mv(...) = FileUtils.mv(@path, ...) def rm(...) = FileUtils.rm(@path, ...) def rm_r(...) = FileUtils.rm_r(@path, ...) def rm_rf(...) = FileUtils.rm_rf(@path, ...) end ``` There are some concerns about making pathname.rb more dependent on FileUtils, which I understand. What's the best way forward? Let's do it! (also see https://github.com/ruby/pathname/issues/64 and https://github.com/ruby/pathname/issues/72) -- https://bugs.ruby-lang.org/

5 6

[ruby-core:124567] [Ruby Feature#13683] Add strict Enumerable#single
by headius (Charles Nutter) 16 Jan '26

16 Jan '26

Issue #13683 has been updated by headius (Charles Nutter). Of the proposed options I still like `one!` best. It conveys both returning a single element and enforcing that there's exactly one. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116141 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124564] [Ruby Feature#13683] Add strict Enumerable#single
by Dan0042 (Daniel DeLorme) 15 Jan '26

15 Jan '26

Issue #13683 has been updated by Dan0042 (Daniel DeLorme). mame (Yusuke Endoh) wrote in #note-48: > But no one seriously considered it because we can find no use case for it. Uh, seriously? I gave an example in #note-16 and we have 11 other similar instances in our codebase. But none that raise an error. Pretty often used as `collection.compact.uniq.single` where we use it as default value for a new record if there is only one. Or, let's say search for product "ABC" and if there is only one match then redirect to it directly, otherwise display the search results. Anyway, I'm just giving my honest feedback. If if turns out the method raises an error, it's no big deal, I'll just keep using our own #single. Eregon (Benoit Daloze) wrote in #note-50: > then `ary.first if ary.size == 1` or so is good enough. That logic doesn't work at all. Of course it's "good enough" but in that case `raise if ary.size != 1` would also be "good enough". ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116138 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124519] [Ruby Feature#21837] Introduce socket hooks in Fiber Scheduler interface
by noteflakes (Sharon Rosner) 15 Jan '26

15 Jan '26

Issue #21837 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Feature #21837: Introduce socket hooks in Fiber Scheduler interface https://bugs.ruby-lang.org/issues/21837 * Author: noteflakes (Sharon Rosner) * Status: Open ---------------------------------------- Currently the fiber scheduler interface does not support any socket operations. The stock Ruby socket implementation performs all operations in a non-blocking way, and invokes the `#io_wait` fiber scheduler hook in order to wait for readiness. I propose adding the following hooks: - `#socket_recv(sock, buffer, length, flags, recvfrom)`: performs a `recv` or `recvfrom`. The `recvfrom` argument is a boolean denoting whether a `recvfrom` should be performed. When true, the hook should return an array containing the number of bytes received and the source address. When false, the hook should return the number of bytes received. - `#socket_send(sock, dest, buffer, length, flags)`: performs a `send` or `sendto`. The `dest` argument is nil for a `send`. When not nil, a `sendto` operation should be done. - `#socket_connect(sock, addr)`: performs a `connect`. - `#socket_accept(sock, client_sockaddr)` - performs an `accept`. The `client_sockaddr` argument is an `IO::Buffer` that receives the peer addrinfo. The PR for this feature: https://github.com/ruby/ruby/pull/15865 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124548] [Ruby Feature#21821] Add Stack and SizedStack classes
by Eregon (Benoit Daloze) 14 Jan '26

14 Jan '26

Issue #21821 has been updated by Eregon (Benoit Daloze). p8 (Petrik de Heus) wrote in #note-11: > The ConditionVariable in Puma 7's thread pool is causing issues in JRuby: [https://github.com/jruby/jruby/issues/9140](https://github.com/jruby/jruby/… I recall it was also causing issues in TruffleRuby back then hence my short attempt to remove it. But we fixed ConditionVariable since then and it seems to work fine now (though indeed there is the overhead of creating a `InterruptedException`, but the whole Java blocking/interruption is basically based on those so seems hard to fix and more of a JVM bug IMO). `ConditionVariable` are a very useful concurrency primitive, so I don't think it's productive in general to try to avoid them, better to optimize them since they are used in plenty of places. > So I thought about attempting to rewrite it without the ConditionVariable (but that is way out of my expertise and now I'm learning not possible with a SizedQueue). Not possible is probably too strong, what I meant to say is when I looked at it and tried it there are some methods I couldn't implement with a SizedQueue, so the API back then and I think the API now has methods which are not implementable with a SizedQueue. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116119 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124547] [Ruby Feature#13683] Add strict Enumerable#single
by Eregon (Benoit Daloze) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by Eregon (Benoit Daloze). @baweaver FYI your reply didn't work on Redmine, it shows an empty comment by Anonymous, so I'd suggest you add on Redmine for future comments to workaround that. The comment is: > I would advocate for using a `!` on the end of whatever we pick to signify it does something "dangerous" (e.g. exception) just as a warning for users. This is not the case for core methods, core methods only have a `!` if it's a more dangerous version of a non-! method, which is not the case here if we add a single method. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116116 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124546] [Ruby Feature#13683] Add strict Enumerable#single
by Eregon (Benoit Daloze) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by Eregon (Benoit Daloze). I think for the use case of "check if a single value" from @Dan0042 then `ary.first if ary.size == 1` or so is good enough. I agree the new method here is meant to assert and the usefulness of it comes from the exception if it unexpectedly doesn't hold. `value = ary.size == 1 ? ary.first : raise(SomeError)` is of course possible but that's quite verbose and I think a pattern worth capturing as a core method. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116115 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124543] [Ruby Feature#13683] Add strict Enumerable#single
by mame (Yusuke Endoh) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by mame (Yusuke Endoh). `Enumerable#sole` is a method that should only be used when the Enumerable has only one element. Using it in other cases (0 or 2+ elements) is considered a bug, or literally "exceptional", so raising an exception makes perfect sense. In the dev meeting, when we consider the name `Enumerable#one!`, I briefly mentioned `Enumerable#one`, a moderate variant that returns `nil` instead of raising an exception. But no one seriously considered it because we can find no use case for it. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116111 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

2 1