December 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:124025] [Ruby Bug#21763] Windows: output IO pipe ignores crlf newline conversion specified by set_encoding
by YO4 (Yoshinao Muramatsu) 07 Jan '26

07 Jan '26

Issue #21763 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21763: Windows: output IO pipe ignores crlf newline conversion specified by set_encoding https://bugs.ruby-lang.org/issues/21763 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On Windows, output pipes have no crlf conversion applied by default except for stdout/stderr, also it ignore set_encoding(crlf_newline: true). ``` > ruby -e "IO.pipe { |r,w| w.set_encoding('ascii-8bit', crlf_newline: true); w.puts ?a; w.close; p r.binmode.read }" "a\n" # => "a\r\n" is expected ``` On other platforms, this is effective. ``` $ ruby -e "IO.pipe { |r,w| w.set_encoding('ascii-8bit', crlf_newline: true); w.puts ?a; w.close; p r.binmode.read }" "a\r\n" ``` This occurs only when using the C runtime _write() for newline conversion. It works correctly when performing CRLF conversion using encoding conversion. ``` > ruby -e "IO.pipe { |r,w| w.set_encoding('us-ascii', crlf_newline: true); w.puts ?a; w.close; p r.binmode.read }" "a\r\n" ``` This also affects an IO duped from stdout. ``` > ruby -e "STDOUT.puts ?a; STDOUT.dup.puts ?b" | ruby -e "p STDIN.binmode.read" "a\r\nb\n" # => "b\n" seems to wrong ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121699] [Ruby Feature#21277] Windows ARM support
by hsbt (Hiroshi SHIBATA) 07 Jan '26

07 Jan '26

Issue #21277 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21277: Windows ARM support https://bugs.ruby-lang.org/issues/21277 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I added the new CI job for Windows ARM support. * https://github.blog/changelog/2025-04-14-windows-arm64-hosted-runners-now-a… * https://github.com/ruby/ruby/pull/13118 We could build Ruby with Windows ARM platform. But `nmake check` is not working yet. I'm tracking that issues on this ticket. ## Can't generate `revision.h` `windows-11-arm` runner couldn't generate `revision.h` with `ruby tool/file2lastrev.rb --revision.h --output=revision.h`. I tried that with git provided by `scoop`. But that is also not working. I confirmed to work `git rev-parse HEAD` directly with `pwsh` of GitHub Actions. But `tool/file2lastrev.rb` returns the followings: ``` Run ruby tool/file2lastrev.rb --revision.h --output=revision.h file2lastrev.rb: git rev-parse failed fatal: unable to access 'NUL': Invalid argument ``` ## `nmake check` is not working https://github.com/ruby/ruby/actions/runs/14564201209/job/40851166866 ``` running file: C:/a/ruby/ruby/src/test/rubygems/test_gem_resolver_index_set.rb A test worker crashed. It might be an interpreter bug or a bug in test/unit/parallel.rb. Try again without the -j option. ``` https://github.com/ruby/ruby/actions/runs/14564667517/job/40852193517 ``` NMAKE : fatal error U1077: '@ .\ruby.exe -I../src/lib -I".ext/arm64-mswin64_140" -I. "../src/tool/runruby.rb" --extout=".ext" -- --disable-gems -r./arm64-mswin64_140-fake -r../src/tool/lib/_tmpdir ../src/spec/mspec/bin/mspec run -B ../src/spec/default.mspec ' : return code '0xc0000005' Stop. ``` They may be caused by Visual Studio 2022 issue same as #21255. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:124357] [Ruby Bug#21803] `Addrinfo#connect_internal` should raise `IO::TimeoutError` on user-specified timeouts
by shioimm (Misaki Shioi) 06 Jan '26

06 Jan '26

Issue #21803 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Bug #21803: `Addrinfo#connect_internal` should raise `IO::TimeoutError` on user-specified timeouts https://bugs.ruby-lang.org/issues/21803 * Author: shioimm (Misaki Shioi) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Background & Proposal `Addrinfo#connect_internal` is a core internal method that is called by both `Addrinfo#connect` and `Addrinfo#connect_from`. It receives a user-specified timeout value from these methods and currently raises `Errno::ETIMEDOUT` when that timeout expires. https://github.com/ruby/ruby/blame/1c07158203f00d020841f2400002f6e9b62d1318… ```ruby def connect_internal(local_addrinfo, timeout=nil) # :yields: socket sock = Socket.new(self.pfamily, self.socktype, self.protocol) begin sock.ipv6only! if self.ipv6? sock.bind local_addrinfo if local_addrinfo if timeout case sock.connect_nonblock(self, exception: false) when 0 # success or EISCONN, other errors raise break when :wait_writable sock.wait_writable(timeout) or raise Errno::ETIMEDOUT, "user specified timeout for #{self.ip_address}:#{self.ip_port}" end while true else sock.connect(self) end ``` However, this timeout is not caused by a system call returning `Errno::ETIMEDOUT`. It is a Ruby-level timeout triggered by explicitly waiting with a user-specified timeout value. This distinction was discussed in another issue: [Introduce general IO#timeout and IO#timeout= for blocking operations](https://bugs.ruby-lang.org/issues/18630)) After that discussion, [Support IO#timeout for rsock_connect](https://github.com/ruby/ruby/pull/11880) introduced a change so that `rsock_connect()` raises `IO::TimeoutError` when a user-specified timeout expires. In addition, `TCPSocket.new` and `Socket.tcp` were updated to align with this behavior, so that they raise `IO::TimeoutError` when a user-specified timeout occurs: [Socket.tcp and TCPSocket.new raise IO::TimeoutError with user specified timeout](https://github.com/ruby/ruby/pull/15602) However, the implementation of `Socket.tcp` still partially relies on `Addrinfo#connect_internal`, specifically in cases where a synchronous connection attempt is made to a single destination. As a result, depending on the execution path, a user-specified timeout may raise either `IO::TimeoutError` or `Errno::ETIMEDOUT`. This inconsistency is undesirable. Therefore, I propose that Addrinfo#connect_internal should raise `IO::TimeoutError` (instead of `Errno::ETIMEDOUT`) when a user-specified timeout expires, to make the behavior consistent across the socket APIs. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:124412] [Ruby Bug#21817] Ruby::Box crashes with refinement + bind_call + Symbol#to_proc combination
by ahogappa (sho hirano) 01 Jan '26

01 Jan '26

Issue #21817 has been reported by ahogappa (sho hirano). ---------------------------------------- Bug #21817: Ruby::Box crashes with refinement + bind_call + Symbol#to_proc combination https://bugs.ruby-lang.org/issues/21817 * Author: ahogappa (sho hirano) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Description When running with `RUBY_BOX=1`, a combination of refinement on Binding class, `bind_call`, and `Symbol#to_proc` causes a crash with the error: `[BUG] BUG: Local ep without cme/box, flags: 66660087` ## Reproduction Script ```ruby # Run with: RUBY_BOX=1 ruby repro.rb using Module.new { refine ::Binding do def eval_methods ::Kernel.instance_method(:methods).bind_call(receiver) end end } p binding.eval_methods.map(&:to_s) ``` ## Expected Behavior The script should return an array of method names as strings. ## Actual Behavior Ruby crashes with `[BUG] BUG: Local ep without cme/box, flags: 66660087` ## Workaround Using block form instead of Symbol#to_proc does not crash: ```ruby binding.eval_methods.map { it.to_s } # This works ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123959] [Ruby Feature#21721] Allow `Queue` and `SizedQueue` to be used as LIFO queues
by byroot (Jean Boussier) 31 Dec '25

31 Dec '25

Issue #21721 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21721: Allow `Queue` and `SizedQueue` to be used as LIFO queues https://bugs.ruby-lang.org/issues/21721 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context Since `Queue` and `SizedQueue` gained a proper timeout mechanism, I've been wanting to use them to implement simpler and more efficient connection pools. However for connection pools you ideally want a LIFO queue because it's preferable to checkout the most recently used connection. ### Problem Both `Queue` and `SizedQueue` only support FIFO because you can only enqueue elements at the beginning of the backing array, and only dequeue at the end. `Queue#push` (aliased as `Queue#<<` and `Queue#enq`) calls `Array#unshift` on the backing array and `Queue#pop` (aliased as `Queue#deq` and `Queue#shift`) calls `Array#pop`. Hence it is impossible to use these two classes for anything other than FIFO queues. I tried to use `git blame` to see if there was a justification for this, but I ended up in a git blame loop around May 2000 https://github.com/ruby/ruby/commit/9da4f78db46764be6dae5e7e83ff48cbecb3fb23 ### Feature I'd like to introduce either of two new methods (or both) to allow for LIFO: - A method to dequeue from the beginning of the backing array (`array_shift`). - A method to enqueue from the end of the backing array (`array_push`). A difficulty I have however is that since the common `shift/pop/push` terms are already used with uncommon meaning, it's hard to come up with good names. Ideas welcome. ### Possible alternatives - Define different classes for LIFO queues - But I find that less flexible, and it means exposing new constant names in the global namespace. - Add an initializer argument to define the queue ordering, e.g. `Queue.new([], lifo: true)` - Similarly, I find this less flexible than to decide the order during enqueue/dequeue - Add an argument to `Queue#pop` and `Queue#push`, e.g. `queue.push(element, front: true)`. -- https://bugs.ruby-lang.org/

6 21

[ruby-core:124410] [Ruby Feature#8948] Frozen regex
by Eregon (Benoit Daloze) 31 Dec '25

31 Dec '25

Issue #8948 has been updated by Eregon (Benoit Daloze). matz (Yukihiro Matsumoto) wrote in #note-35: > I still do not see enough benefit in putting in incompatible changes. Even if we can rewrite all the gems, we will still have incompatibility issues in user applications. It seems extremely unlikely that applications subclass Regexp, or add instance variables to Regexps (which already doesn't work for literal Regexps). I would expect something like maybe 1 application in a million do that. The benefits are: * Non-literal Regexps are frozen too, which means they can be used with Ractor. * Simplicity for the semantics and users: all Regexps are frozen, not "some Regexps are frozen" and some not, when the internal state of a Regexp has always been immutable anyway. * Improved compatibility between Ruby implementations. The cons are: * A few gems out of ~188000 gems seem affected. It's not complicated to update the code to avoid relying on mutable Regexps (there is no need to subclass Regexp, one can just delegate the relevant methods). * A few applications might be affected. * In either case, I expect this potential incompatibility won't be noticed by 99.9+% users. ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-115928 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Assignee: Eregon (Benoit Daloze) * Target version: 4.1 ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124407] [Ruby Feature#8948] Frozen regex
by matz (Yukihiro Matsumoto) 30 Dec '25

30 Dec '25

Issue #8948 has been updated by matz (Yukihiro Matsumoto). Eregon (Benoit Daloze) wrote in #note-34: > @matz Is it OK to merge https://github.com/ruby/ruby/pull/14547 now for 4.1? I still do not see enough benefit in putting in incompatible changes. Even if we can rewrite all the gems, we will still have incompatibility issues in user applications. Matz. ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-115925 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Assignee: Eregon (Benoit Daloze) * Target version: 4.1 ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124401] [Ruby Feature#8948] Frozen regex
by Eregon (Benoit Daloze) 30 Dec '25

30 Dec '25

Issue #8948 has been updated by Eregon (Benoit Daloze). @matz Is it OK to merge https://github.com/ruby/ruby/pull/14547 now for 4.1? Then there is plenty of time for the few gems that rely on mutable Regexp to adapt. BTW I noticed someone else also did a PR for this, so there seems to be some interest: https://github.com/ruby/ruby/pull/15762 ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-115919 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Assignee: Eregon (Benoit Daloze) * Target version: 4.1 ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124207] [Ruby Bug#21784] Proc#source_location start column seems strange for -> {}
by Eregon (Benoit Daloze) 30 Dec '25

30 Dec '25

Issue #21784 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21784: Proc#source_location start column seems strange for -> {} https://bugs.ruby-lang.org/issues/21784 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-14T07:11:02Z master 711d14992e) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ ruby -e 'p -> { a }.source_location' ["-e", 1, 4, 1, 10] ``` So it considers the stabby lambda to be at: ```ruby p -> { a }.source_location ^^^^^^ ``` Note it starts at a whitespace after the `->`. I think it should just include the `->`, i.e. return `["-e", 1, 2, 1, 10]`. Or possibly start at the `{`, i.e. return `["-e", 1, 3, 1, 10]`. But starting on a whitespace like here seems really strange, it looks like a bug. It's the same result with `--parser=parse.y`, so I don't show it. --- For context: For Procs/block it looks like this: ``` $ ruby -e 'p proc { a }.source_location' ["-e", 1, 7, 1, 12] ``` ```ruby p proc { a }.source_location ^^^^^ ``` This looks fine. The block could of course be given to any other method so it won't always be `proc` in front. Maybe it could include the method too (so it would return start column 2 here), I think either is fine. For `for` blocks it looks like this: ``` $ ruby -e ' def self.each(&b); yield b; end; for b in self 42 end p b.source_location' ["-e", 3, 0, 5, 3] ``` That is, it covers the entire `for` expression from `for` until `end`. I think that's good and fine as-is. For `def` methods it covers everything from `def` to `end` (or end of line for `def m = 42`), as expected. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:124206] [Ruby Bug#21783] {Method,UnboundMethod,Proc}#source_location returns columns in bytes and not in characters
by Eregon (Benoit Daloze) 30 Dec '25

30 Dec '25

Issue #21783 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21783: {Method,UnboundMethod,Proc}#source_location returns columns in bytes and not in characters https://bugs.ruby-lang.org/issues/21783 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-14T07:11:02Z master 711d14992e) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The documentation says: ``` = Proc.source_location (from ruby core) ------------------------------------------------------------------------ prc.source_location -> [String, Integer, Integer, Integer, Integer] ------------------------------------------------------------------------ Returns the location where the Proc was defined. The returned Array contains: (1) the Ruby source filename (2) the line number where the definition starts (3) the column number where the definition starts (4) the line number where the definition ends (5) the column number where the definitions ends This method will return nil if the Proc was not defined in Ruby (i.e. native). ``` So it talks about column numbers, so it should be a number of characters and not of bytes. But currently it's a number of bytes: ``` $ ruby --parser=prism -ve 'def été; end; p method(:été).source_location' ruby 4.0.0dev (2025-12-14T07:11:02Z master 711d14992e) +PRISM [x86_64-linux] ["-e", 1, 0, 1, 14] ruby --parser=parse.y -ve 'def été; end; p method(:été).source_location' ruby 4.0.0dev (2025-12-14T07:11:02Z master 711d14992e) [x86_64-linux] ["-e", 1, 0, 1, 14] ``` The last number should be 12 because `"def été; end".size` is 12 characters. This is a Ruby-level API so I would never expect "byte columns" here, I think it's clear it should be a number of "editor columns" i.e. a number of characters. -- https://bugs.ruby-lang.org/

5 21