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

[ruby-core:123829] [Ruby Bug#21691] On Windows some of binary read functions of IO are not functional
by YO4 (Yoshinao Muramatsu) 08 Jan '26

08 Jan '26

Issue #21691 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21691: On Windows some of binary read functions of IO are not functional https://bugs.ruby-lang.org/issues/21691 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When using the binary read method of IO on a file containing “\r\n”, it should read “\r”, but some methods do not function correctly on Windows. ```ruby File.binwrite("crlf.txt", "\r\n") methods = { readn: proc { |f| f.read(1) }, getbyte: proc { |f| f.getbyte.chr }, readbyte: proc { |f| f.readbyte.chr }, readpartial: proc { |f| f.readpartial(1) }, read_nonblock: proc { |f| f.read_nonblock(1) }, sysread: proc { |f| f.sysread(1) }, pread: proc { |f| f.pread(1, 0) }, } def test(mode, name, method) open("crlf.txt", "r") do |f| p [mode, name, method.call(f)] end end methods.each { |k, v| test("r", k, v) } methods.each { |k, v| test("rt", k, v) } ``` results: ```ruby ["r", :readn, "\r"] ["r", :getbyte, "\n"] # => shold be "\r" ["r", :readbyte, "\n"] # => shold be "\r" ["r", :readpartial, "\n"] # => shold be "\r" ["r", :read_nonblock, "\n"] # => shold be "\r" ["r", :sysread, "\n"] # => shold be "\r" ["r", :pread, "\r"] ["rt", :readn, "\r"] ["rt", :getbyte, "\n"] # => shold be "\r" ["rt", :readbyte, "\n"] # => shold be "\r" ["rt", :readpartial, "\n"] # => shold be "\r" ["rt", :read_nonblock, "\n"] # => shold be "\r" ["rt", :sysread, "\n"] # => shold be "\r" ["rt", :pread, "\r"] ``` On Ubuntu in WSL, all returns are “\r”. -- https://bugs.ruby-lang.org/

2 1

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

08 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:124029] [Ruby Bug#21765] stop using the C runtime _read() on Windows
by YO4 (Yoshinao Muramatsu) 08 Jan '26

08 Jan '26

Issue #21765 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21765: stop using the C runtime _read() on Windows https://bugs.ruby-lang.org/issues/21765 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When creating an IO instance in Windows, the default data mode is text mode. In reality, the IO encoding conversion mechanism is not used when encoding conversion is not performed. Instead, the CRLF conversion provided by the C runtime's `_read()` is used. This is explicitly for speed. https://bugs.ruby-lang.org/issues/6401#note-4 As a trade-off, `SET_BINARY_MODE(fptr)` and `SET_BINARY_MODE_WITH_SEEK_CUR(fptr)` are used in various places within io.c, altering the state of the file descriptor. This made the flow of operations difficult to understand and changes hard to implement, especially for developers on other platforms. Additionally, the issues I recently reported were discovered while verifying the impact of modifying the CRLF conversion to utilize the encoding conversion mechanism. #21691 On Windows some of binary read functions of IO are not functional #21687 IO＃pos goes wrong after EOF character(ctrl-z) met #21634 Combining read(1) with eof? causes dropout of results unexpectedly on Windows. These issues arise because data read into the rbuf does not match the stream due to newline conversion, or because the buffer end and file position do not align when CTRLZ is detected. As a fix for Bug #21687, I created PR #15216. However, this relies on the internal behavior of the C runtime's `_read()` function, and it seems there is no way to avoid this dependency. **I propose removing the use of C runtime _read().** Reason for Proposal - The mismatch between rbuf and stream contents complicates io_unread() and makes maintenance difficult. - Changing the O_BINARY/O_TEXT state of the file descriptor in various places hinders understanding of the behavior and makes modifications difficult. Two methods to remove C runtime _read() while maintaining current behavior 1. Interpret CRLF and CTRLZ when reading rbuf within io.c. 1. Interpret CRLF and CTRLZ within the encoding conversion framework. My initial idea was to implement the second, using encoding conversion. However, this internally changes the read operation from rbuf to cbuf, resulting in a change to the behavior of ungetc. The proposal in Bug #21682 attempted to generalize this change to minimize its impact. https://bugs.ruby-lang.org/issues/21682 **This issue proposes the first method, crlf conversion during rbuf read.** Problems caused by inconsistencies between the rbuf and stream contents are avoided, and io_unread() becomes the same as on other platforms. Compared to implementing it as an encoding conversion, the advantage is that there is no change in behavior. On the other hand, since each read method in io.c requires individual handling, using encoding conversion results in more localized changes. -- https://bugs.ruby-lang.org/

2 3

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

08 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) 07 Jan '26

07 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) 02 Jan '26

02 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) 31 Dec '25

31 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