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

[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

[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:120488] [Ruby master Feature#21005] Update the source location method to include line start/stop and column start/stop details
by bkuhlmann (Brooke Kuhlmann) 30 Dec '25

30 Dec '25

Issue #21005 has been reported by bkuhlmann (Brooke Kuhlmann). ---------------------------------------- Feature #21005: Update the source location method to include line start/stop and column start/stop details https://bugs.ruby-lang.org/issues/21005 * Author: bkuhlmann (Brooke Kuhlmann) * Status: Open ---------------------------------------- ## Why 👋 Hello. After discussing with Kevin Newton and Benoit Daloze in [Feature 20999](https://bugs.ruby-lang.org/issues/20999), I'd like to propose adding line start/stop and column start/stop information to the `#source_location` method for the following objects: - [Binding](https://docs.ruby-lang.org/en/master/Binding.html) - [Proc](https://docs.ruby-lang.org/en/master/Proc.html) - [Method](https://docs.ruby-lang.org/en/master/Method.html) - [UnboundMethod](https://docs.ruby-lang.org/en/master/UnboundMethod.html) At the moment, when using `#source_location`, you only get the following information: ``` ruby def demo = "A demonstration." # From disk. method(:demo).source_location # ["/Users/bkuhlmann/Engineering/Misc/demo", 15] # From memory. method(:demo).source_location # ["(irb)", 3] ``` Notice, when asking for the source location, we only get the path/location as the first element and the line number as the second element but I'd like to obtain a much richer set of data which includes line start/stop and column start/stop so I can avoid leaning on the `RubyVM` for this information. Example: ``` ruby def demo = "A demonstration." # From disk. instructions = RubyVM::InstructionSequence.of method(:demo) puts [instructions.absolute_path, *instructions.to_a.dig(4, :code_location)] [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 0, # Column start. 15, # Line stop. 29 # Column stop. ] # From memory. instructions = RubyVM::InstructionSequence.of method(:demo) puts instructions.script_lines [ "def demo = \"A demonstration.\"\n", "" ] ``` By having access to the path (or lack thereof in case of IRB), line start/stop, and column start/stop, this means we could avoid using the RubyVM to obtain raw source code for any of these objects. This would not only enhance debugging situations but also improve Domain Specific Languages that wish to leverage this information for introducing new features and/or new debugging capabilities to the language. ## How Building upon the examples provided above, I'd like to see `Binding`, `Proc`, `Method`, and `UnboundMethod` respond to `#source_location` as follows: ``` ruby [ "/Users/bkuhlmann/Engineering/Misc/demo", # Source path. 15, # Line start. 15, # Line stop. 0, # Column start. 29 # Column stop. ] ``` Notice, for data grouping purposes, I changed the array structure to always start with the path as the first element, followed by line information, and ending with column information. Alternatively, it could might be nice to improve upon the above by answering a hash each time, instead, for a more self-describing data structure. Example: ``` ruby { path: "/Users/bkuhlmann/Engineering/Misc/demo", line_start: 15, line_stop: 15, column_start: 0, column_stop: 29 } ``` For in-memory, situations like IRB, it would be nice to answer the equivalent of `RubyVM::InstructionSequence#script_lines` which would always be an `Array` with no line or column information since only the source code is necessary. Example: ``` ruby [ "def demo = \"A demonstration.\"\n", "" ] ``` From a pattern matching perspective, this could provide the best of both worlds especially if information is answered as either a `Hash` or and `Array`. Example: ``` def demo = "A demonstration." case method(:demo).source_location in Hash then puts "Source information obtained from disk." in Array then puts "Source obtained from memory." else fail TypeError, "Unrecognized source location type." end ``` This above is only a simple example but there's a lot we could do with this information if the above pattern match was enhanced to deal with the extraction and formatting of the actual source code! ## Notes This feature request is related to the following discussions in case more context is of help: - [Feature 6012](https://bugs.ruby-lang.org/issues/6012) - [Feature 20999](https://bugs.ruby-lang.org/issues/20999) -- https://bugs.ruby-lang.org/

8 19