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

[ruby-core:119895] [Ruby master Bug#20889] IO#ungetc and IO#ungetbyte should not cause IO#pos to report an inaccurate position
by javanthropus (Jeremy Bopp) 13 Nov '25

13 Nov '25

Issue #20889 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Bug #20889: IO#ungetc and IO#ungetbyte should not cause IO#pos to report an inaccurate position https://bugs.ruby-lang.org/issues/20889 * Author: javanthropus (Jeremy Bopp) * Status: Open * ruby -v: ruby 3.3.6 (2024-11-05 revision 75015d4c1f) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8') do |f| f.write('0123456789') f.rewind f.ungetbyte(93) f.pos # => -1; negative value is surprising! end Tempfile.open(encoding: 'utf-8') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-8')) f.pos # => -1; similar to the ungetbyte case end Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.ungetc('a'.encode('utf-16le')) f.pos # => 0; maybe should be -2 to match the previous ungetc case? end ``` It doesn't seem logical that `IO#pos` should ever be affected by `IO#ungetc` or `IO#ungetbyte`. The pushed characters or bytes aren't really in the stream source. The value of `IO#pos` implies that jumping directly to that position via `IO#seek` and reading from there would return the same character or byte that was pushed, but the pushed characters or bytes are lost when the operation to seek in the stream is performed. In the case where `IO#pos` is a negative value, attempting to seek to that position actually raises an exception. In the `IO#ungetc` with character conversion case above, it seems unreasonable to make `IO#pos` report an even less correct position. In that case, the position would need to be adjusted by 2 bytes in reverse due to the internal encoding of the stream, but that is completely inconsistent with the behavior of `IO#pos` when reading from the stream normally where it reports the underlying stream's byte position and not the number of transcoded bytes that have been read: ```ruby require 'tempfile' Tempfile.open(encoding: 'utf-8:utf-16le') do |f| f.write('0123456789') f.rewind f.getc.bytesize # => 2; due to the internal encoding of the stream f.pos # => 1; reports actual bytes read from the stream, not transcoded bytes end ``` Attempting to use `IO#pos` when there are characters or bytes pushed into the read buffer by way of `IO#ungetc` or `IO#ungetbyte` should result in one of the following behaviors: 1. Raise and exception 2. Return the stream's position, clearing the read buffer entirely 3. Return the stream's position, ignoring the pushed characters or bytes, and produce a warning -- https://bugs.ruby-lang.org/

2 1

[ruby-core:122773] [Ruby Feature#21513] Raise on converting endless range to set
by viralpraxis (Iaroslav Kurbatov) 13 Nov '25

13 Nov '25

Issue #21513 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Feature #21513: Raise on converting endless range to set https://bugs.ruby-lang.org/issues/21513 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open ---------------------------------------- Converting endless range to array raises: ``` shell ruby -e '(1..).to_a' -e:1:in 'Range#to_a': cannot convert endless range to an array (RangeError) from -e:1:in '<main>' ``` but converting to set does not: ``` shell ruby -e '(1..).to_set # hangs' ``` I think it makes to raise in both cases for consistency. Something like this should do the trick: ``` diff diff --git i/prelude.rb w/prelude.rb index f49cada637..11bfa3fc95 100644 --- i/prelude.rb +++ w/prelude.rb @@ -30,6 +30,10 @@ module Enumerable # Makes a set from the enumerable object with given arguments. # Passing arguments to this method is deprecated. def to_set(*args, &block) + if self.class == Range && self.end.nil? + raise RangeError, "cannot convert endless range to a set" + end + klass = if args.empty? Set else diff --git i/test/ruby/test_range.rb w/test/ruby/test_range.rb index f875c0ab40..27b968641b 100644 --- i/test/ruby/test_range.rb +++ w/test/ruby/test_range.rb @@ -1541,4 +1541,11 @@ def test_overlap? assert_not_operator((1...3), :overlap?, (3..4)) assert_not_operator((...3), :overlap?, (3..)) end + + def test_to_set + assert_equal(Set[], (1..-1).to_set) + assert_equal(Set[1, 2, 3], (1..3).to_set) + + assert_raise(RangeError) { (239..).to_set } + end end ``` If this patch is accepted, I'll open a PR. ``` shell ./ruby -v ruby 3.5.0dev (2025-07-14T20:34:32Z master a6d483971a) +PRISM [x86_64-linux] ``` -- https://bugs.ruby-lang.org/

5 7

[ruby-core:123775] [Ruby Misc#21681] Clarification on the Status and Roadmap of Ruby Box for Ruby 4.0
by dmitry.pogrebnoy (Dmitry Pogrebnoy) 13 Nov '25

13 Nov '25

Issue #21681 has been reported by dmitry.pogrebnoy (Dmitry Pogrebnoy). ---------------------------------------- Misc #21681: Clarification on the Status and Roadmap of Ruby Box for Ruby 4.0 https://bugs.ruby-lang.org/issues/21681 * Author: dmitry.pogrebnoy (Dmitry Pogrebnoy) * Status: Open ---------------------------------------- Hello! I’d like to ask about the expected state of Ruby Box in the upcoming Ruby 4.0 release. I came across the roadmap here: https://bugs.ruby-lang.org/versions/105, which mentions the related feature: https://bugs.ruby-lang.org/issues/21311. From the discussion, it seems there are several concerns around the proposal. I also noticed that the name Ruby Box originated from this thread: https://bugs.ruby-lang.org/issues/21385. In that discussion, it was mentioned that Ruby Box is expected to serve as a low-level API. However, I haven’t found any information about a potential high-level API built on top of it. Since I’d like to plan ahead and ensure that development tools can support this new feature and its adoption, could you please clarify: * Given the threads mentioned above, what is the final vision/scope of the Ruby Box feature? I appreciate if you point me towards relevant documentation. * Is Ruby Box expected to be included by default in Ruby 4.0 (as usual planned for late December if I got it right)? * What is the general plan or roadmap for Ruby Box? Are there any intentions to introduce a high-level API or additional related features? Thank you very much for your time and for any insights you can share. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123781] [Ruby Bug#18878] parse.y: Foo::Bar {} is inconsistently rejected
by yui-knk (Kaneko Yuichiro) 13 Nov '25

13 Nov '25

Issue #18878 has been updated by yui-knk (Kaneko Yuichiro). Pull Request: https://github.com/ruby/ruby/pull/15165 ---------------------------------------- Bug #18878: parse.y: Foo::Bar {} is inconsistently rejected https://bugs.ruby-lang.org/issues/18878#change-115172 * Author: qnighy (Masaki Hara) * Status: Assigned * Assignee: ydah (Yudai Takada) * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- The following source doesn't parse: ```ruby Foo::Bar {} ``` despite the following: ```ruby bar # local variable or method call Bar # constant bar() # method call Bar() # method call bar {} # method call Bar {} # method call bar() {} # method call Bar() {} # method call Foo::bar # method call Foo::Bar # constant Foo::bar() # method call Foo::Bar() # method call Foo::bar {} # method call # Foo::Bar {} # SyntaxError Foo::bar() {} # method call Foo::Bar() {} # method call ``` Especially considering `Bar {}`, this looks like a missing implementation rather than an intentional behavior. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123776] [Ruby Bug#21682] The result of IO#pos is inconsistent after using IO#ungetc.
by YO4 (Yoshinao Muramatsu) 13 Nov '25

13 Nov '25

Issue #21682 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21682: The result of IO#pos is inconsistent after using IO#ungetc. https://bugs.ruby-lang.org/issues/21682 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In this issue, I propose modifying `IO#ungetc` to never change the file position and explain the reasons for this change. The file location after using IO#ungetc may or may not change. This behavior is not documented. Since there are cases that the file position cannot be modified, I propose to unify the behavior so that the file position is not changed. ## Motivation Ensure file position behavior is independent of I/O setup. Avoid excessive exposure of implementation details. ## Current Details The file position after using IO#ungetc depends on the following conditions: When encoding conversion is not used: It changes. When encoding conversion is used: It does not change. This corresponds internally to whether the ungetc character is stored in the IO object's rbuf or cbuf. When using cbuf, the byte count of a character in cbuf may differ from its byte count in rbuf, making conversion from cbuf byte count to rbuf byte count potentially complex. Furthermore, even if one reverse-converts a character in cbuf to calculate its byte count in rbuf, the practical significance of this calculation is questionable. Therefore, it appears that adjusting the buffered byte count from the actual file position to calculate the file position in Ruby when a character exists in cbuf is not implemented. When stored in rbuf, its byte count can be used to calculate the file position, so the file position moves due to ungetc. ## Problems It seems relatively unknown that the side effects of ungetc can change depending on I/O setup. The Ruby community doesn't seem to discuss avoiding the use of file positions after ungetc. Behavior changing under little-known conditions reduces test coverage and leaves potential bugs. On Windows, files opened in "r" mode perform CRLF conversion but operate without encoding conversion, delegating conversion to the C runtime library (CRT). This is primarily for speed, but it modifies IO state in various places within io.c, reducing readability. It has also caused numerous bugs related to file position. Unfortunately, in Windows, "r" and "rt" are not equivalent depending on whether encoding conversion is used or not. This means the behavior of ungetc cannot be predicted within the context of 'text mode'. I'm working personally on switching to use encoding conversion instead of CRT read(), which means encoding conversion will be used for files opened with "r". This change will alter the behavior of ungetc. This impact occurs because implementation details are being exposed excessively, which is undesirable. ## Changes and Impact IO#ungetc will no longer change the file position. This affects not only IO#pos, but also implicitly impacts the file position when writing after ungetc. TestIO#test_copy_stream_dst_rbuf depends on this behavior. Changing the behavior of IO#ungetbyte is outside the scope of this issue. Changing it caused many tests to fail, but the details have not been investigated. Since IO#ungetbyte changes the file position while IO#ungetc does not, mixing their use is no longer possible. This means that performing ungetbyte after unetc before reading the entire data will cause an exception. /test/ruby/test_io.rb fails due to the above implicit dependency, and /spec/ruby/core/io/ungetc_spec.rb fails due to a test explicitly checking IO#pos. I have no idea about investigating the impact of real-world usage. ## Another approach Do not modify Ruby's behavior. Instead, document that the file position after using IO#ungetc cannot be trusted. Alternatively, it might be possible to issue a warning during specific operations when characters from IO#ungetc remain pending. In these cases, when Windows is switched to use encoding conversion for "r", io_unread() and rb_io_tell() will also take into account the number of bytes in cbuf in addition to rbuf to maintain compatibility. I prefer to minimize code for specific environments, so this is not to my ideal. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123778] [Ruby Bug#21683] IO#each_codepoint do not take care of encoding when IO uses encoding conversion for reading.
by YO4 (Yoshinao Muramatsu) 12 Nov '25

12 Nov '25

Issue #21683 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #21683: IO#each_codepoint do not take care of encoding when IO uses encoding conversion for reading. https://bugs.ruby-lang.org/issues/21683 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * ruby -v: ruby 3.5.0dev (2025-11-03T10:33:44Z master 0832e954c9) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- without encoding conversion ```irb irb(main):001> open(File::NULL, 'r') { |f| f.ungetc(%Q[\u{3042}\u{3044}\u{3046}]); f.each_codepoint.map { |c| c.to_s(16) } } => ["3042", "3044", "3046"] # => valid ``` with encoding conversion ```irb irb(main):001> open(File::NULL, 'rt') { |f| f.ungetc(%Q[\u{3042}\u{3044}\u{3046}]); f.each_codepoint.map { |c| c.to_s(16) } } => ["e3", "81", "82", "e3", "81", "84", "e3", "81", "86"] # => invalid ``` prior to ruby 3.4 lacks 6cd98c24fe9aeea3829ac3d554a277f053cec0be (Allow IO#each_codepoint to work with unetc even when encoding conversion active) using ungetbyte can similarly reproduce this. ```irb irb(main):001> open(File::NULL, 'rt') { |f| f.ungetbyte(%Q[\u{3042}\u{3044}\u{3046}]); p f.each_codepoint.map { |c| c.to_s(16) } } => ["e3", "81", "82", "e3", "81", "84", "e3", "81", "86"] ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123724] [Ruby Bug#21672] `IO::Buffer.new` does not check that flags are valid
by trinistr (Alexander Bulancov) 11 Nov '25

11 Nov '25

Issue #21672 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Bug #21672: `IO::Buffer.new` does not check that flags are valid https://bugs.ruby-lang.org/issues/21672 * Author: trinistr (Alexander Bulancov) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `IO::Buffer.new` has a `flags` argument that allows to override automatic decision between INTERNAL and MAPPED. As far as I understand, these modes are supposed to be exclusive, however in practice there is no check, and the user is free to specify both: ``` IO::Buffer.new(10, IO::Buffer::MAPPED|IO::Buffer::INTERNAL) # => # #<IO::Buffer 0x0000555bfdccf760+10 INTERNAL MAPPED> # 0x00000000 00 00 00 00 00 00 00 00 00 00 .......... ``` From the source code in https://github.com/ruby/ruby/blob/master/io_buffer.c#L204, the real mode seems to be INTERNAL. I imagine that the order of branches can be reversed with changes, suddenly changing behavior. Even worse, if at least one of `INTERNAL` or `MAPPED` is specified, flags are not checked at all, allowing complete nonsense: ``` IO::Buffer.new(10, 0xffffff) # #<IO::Buffer 0x000055672a653190+10 EXTERNAL INTERNAL MAPPED SHARED LOCKED PRIVATE READONLY> ``` `IO::Buffer.map` also exhibits this issue, though I'm unsure if this combination of flags is actually invalid (it at least doesn't get LOCKED): ``` IO::Buffer.map(File.open('README.md', 'r+'), nil, 0, 0xffffff) # #<IO::Buffer 0x00007fd8edb90000+9024 MAPPED FILE PRIVATE READONLY> ``` -- https://bugs.ruby-lang.org/

4 5

[ruby-core:123538] [Ruby Misc#21647] DevMeeting-2025-11-13
by mame (Yusuke Endoh) 11 Nov '25

11 Nov '25

Issue #21647 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21647: DevMeeting-2025-11-13 https://bugs.ruby-lang.org/issues/21647 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/11/13 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/11/10. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

8 7

[ruby-core:123474] [Ruby Feature#21637] Tracing global variable assignment
by viralpraxis (Iaroslav Kurbatov) 11 Nov '25

11 Nov '25

Issue #21637 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Feature #21637: Tracing global variable assignment https://bugs.ruby-lang.org/issues/21637 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open ---------------------------------------- ## Motivation Currently, there is no straightforward way to track global variable assignments at runtime. The only workaround I am aware of involves using the `line` TracePoint event, combined with manipulation of the source code's AST, but this approach is extremely slow and impractical. I'd like to propose a new `gvar_set` (and probably `gvar_get`, but that's out of the scope of this ticket) event which would fire whenever a global variable is written to. ## Context There's current an open https://bugs.ruby-lang.org/issues/15854 feature request with a PR by @st0012, but they currently do not address the global variables, so I've decided to open a new one and a new PR. There's an open gvar-specific question: should "system" global variables like `$!` trigger the `gvar_set` event? (the current implementation does not) ## Usage example ```ruby # frozen-string-literal: true TracePoint.new(:gvar_set) { p [it.gvar_name, it.return_value] }.enable do $G1 = 1 $G2 = 2 $G3 = 3 end # [:$G1, 1] # [:$G2, 2] # [:$G3, 3] ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:122343] [Ruby Misc#21385] Namespace: Suggesting a rename
by fxn (Xavier Noria) 11 Nov '25

11 Nov '25

Issue #21385 has been reported by fxn (Xavier Noria). ---------------------------------------- Misc #21385: Namespace: Suggesting a rename https://bugs.ruby-lang.org/issues/21385 * Author: fxn (Xavier Noria) * Status: Open ---------------------------------------- I'd like to suggest a rename of namespaces. The word "namespace" is already taken in Ruby. We say that classes and modules act as or represent. Constant paths nest them in practice. We say that it is a best practice that gems create their own namespace, etc. If the feature goes ahead with this name, the above sentences, well-established in the Ruby community, will start to sound confusing, because that meaning of "namespace" stays. If you look at the index in Matz's book, "namespaces" is indexed in pages 248–250. Title of section 7.5.1 is "Modules as Namespaces". Besides, I have had a few experiences explaining the proposal to people, and quickly realizing they assume this is something like C++ namespaces or Java packages. Then, I have to undo that mental model and start all over saying "forget that mental model". Those are like our constant paths, only more simple and strict. I think it may also be confusing in this sense (though this could be OK if it wasn't for the previous point.) To be constructive: Some alternative names that I have thought about are "isolates", "shields", or "cells". ("sandboxes" is close, but may have security connotations you do not want to suggest.) -- https://bugs.ruby-lang.org/

18 32