October 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: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) 10 Nov '25

10 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

[ruby-core:123595] [Ruby Misc#21657] Question: Is Ruby 4.0 planned for December 2025 or later?
by dmitry.pogrebnoy (Dmitry Pogrebnoy) 10 Nov '25

10 Nov '25

Issue #21657 has been reported by dmitry.pogrebnoy (Dmitry Pogrebnoy). ---------------------------------------- Misc #21657: Question: Is Ruby 4.0 planned for December 2025 or later? https://bugs.ruby-lang.org/issues/21657 * Author: dmitry.pogrebnoy (Dmitry Pogrebnoy) * Status: Open ---------------------------------------- Hello Ruby core team, I noticed that the first preview of Ruby 3.5 has been released, and at the same time there’s some talk in the community about Ruby 4.0 potentially arriving in December 2025. Could you please clarify what the current roadmap looks like? Is Ruby 4.0 already planned for this December, or is the next stable release still Ruby 3.5? Having a clear, public roadmap would really help library and tooling authors (like IDE vendors) prepare for upcoming versions and provide better support. Thank you! -- https://bugs.ruby-lang.org/

10 22

[ruby-core:123389] [Ruby Feature#21625] Allow IO#wait_readable together with IO#ungetc
by YO4 (Yoshinao Muramatsu) 07 Nov '25

07 Nov '25

Issue #21625 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Feature #21625: Allow IO#wait_readable together with IO#ungetc https://bugs.ruby-lang.org/issues/21625 * Author: YO4 (Yoshinao Muramatsu) * Status: Open ---------------------------------------- ### Background IO#wait_readable calles rb_io_check_byte_readable() in that C implementation, so that is treated as binary reading class operation. ```ruby open(IO::NULL, "rt") { |f| f.ungetc(?a); f.wait_readable } # => in 'IO#wait_readable': byte oriented read for character buffered IO (IOError) ``` This is inconsistent with the behavior of IO#select. ```ruby open(IO::NULL, "rt") { |f| f.ungetc(?a); IO.select([f]) } # => [[#<File:NUL (closed)>], [], []] ``` ### Proposal Change IO#wait_readable into character reading class function. This allows mixing usage of IO#wait_readable and IO#ungetc. This change avoids the IOError that previously occurred, but in that case, an exception is thrown when the binary read method is subsequently called. Overall behavior remains unchanged, but exceptions will occur at more desirable locations. If the method being called next is a character method, no exception will be thrown. But that is the desired behavior. ### related methods IO#io_wait_priority may apply similar changes for consistency. IO#ready? seems to have the same issue. This is in the io-wait default gem. IO#wait already respects the character read buffer. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123477] [Ruby Bug#21638] Ractor-local `$DEBUG` is not marked
by nobu (Nobuyoshi Nakada) 07 Nov '25

07 Nov '25

Issue #21638 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21638: Ractor-local `$DEBUG` is not marked https://bugs.ruby-lang.org/issues/21638 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- https://github.com/sampersand/blog/blob/master/the%20-s%20flag.md#the-segfa… -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123575] [Ruby Feature#21653] Unify Hash methods and preserving default/default_proc
by andrykonchin (Andrew Konchin) 07 Nov '25

07 Nov '25

Issue #21653 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Feature #21653: Unify Hash methods and preserving default/default_proc https://bugs.ruby-lang.org/issues/21653 * Author: andrykonchin (Andrew Konchin) * Status: Open ---------------------------------------- All the Hash methods that return a new instance of Hash don't preserve the `default` and `default_proc` properties except `#compact` and `#merge`: ```ruby h = {a: 1} h.default = 0 h.compact[:f] == 0 # => true h.merge(b: 2)[:f] == 0 # => true ``` Propose to unify Hash methods select/slice/reject/except/compact/merge/transform_values/transform_keys/invert/to_h/Hash[] and to preserve or not preserve default/default_proc altogether. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123500] [Ruby Bug#21644] Stack consistency error for the `newrange` INSN peephole optimization with chilled string
by viralpraxis (Iaroslav Kurbatov) 05 Nov '25

05 Nov '25

Issue #21644 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #21644: Stack consistency error for the `newrange` INSN peephole optimization with chilled string https://bugs.ruby-lang.org/issues/21644 * Author: viralpraxis (Iaroslav Kurbatov) * 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 ---------------------------------------- PR:https://github.com/ruby/ruby/pull/14879 Confirmed on every version since 3.4. ``` shell $ ruby -v -e '("a" || "b").."c"' ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] -e:1: warning: possibly useless use of .. in void context -e:1: [BUG] Stack consistency error (sp: 7, bp: 6) ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0002 p:0013 s:0007 e:000005 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:001920 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- -e:1:in '<main>' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- ruby/3.4.7/lib/libruby.so.3.4(rb_print_backtrace+0x8) [0x78aa9573c882] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm_dump.c:823 ruby/3.4.7/lib/libruby.so.3.4(rb_vm_bugreport) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm_dump.c:1155 ruby/3.4.7/lib/libruby.so.3.4(rb_bug_without_die_internal+0x6b) [0x78aa9544c62f] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/error.c:1097 ruby/3.4.7/lib/libruby.so.3.4(rb_bug) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/error.c:1115 ruby/3.4.7/lib/libruby.so.3.4(vm_stack_consistency_error+0x1f) [0x78aa9544f091] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm_insnhelper.c:6523 ruby/3.4.7/lib/libruby.so.3.4(vm_get_cref) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/insns.def:1134 ruby/3.4.7/lib/libruby.so.3.4(vm_setclassvariable) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm_insnhelper.c:1630 ruby/3.4.7/lib/libruby.so.3.4(vm_setclassvariable) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm_insnhelper.c:1627 ruby/3.4.7/lib/libruby.so.3.4(vm_exec_core) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/insns.def:253 ruby/3.4.7/lib/libruby.so.3.4(vm_exec_loop+0xa) [0x78aa95724959] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm.c:2622 ruby/3.4.7/lib/libruby.so.3.4(rb_vm_exec) /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/vm.c:2598 ruby/3.4.7/lib/libruby.so.3.4(rb_ec_exec_node+0xa5) [0x78aa95525695] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/eval.c:281 ruby/3.4.7/lib/libruby.so.3.4(ruby_run_node+0x83) [0x78aa95529333] /tmp/ruby-build.20251010151551.31019.jR04SY/ruby-3.4.7/eval.c:319 ruby/3.4.7/bin/ruby(rb_main+0x21) [0x59d86f5e0186] ./main.c:43 ruby/3.4.7/bin/ruby(main) ./main.c:68 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main+0x7a) [0x78aa9502a1ca] ../sysdeps/nptl/libc_start_call_main.h:58 /lib/x86_64-linux-gnu/libc.so.6(call_init+0x0) [0x78aa9502a28b] ../csu/libc-start.c:360 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) ../csu/libc-start.c:347 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main) (null):0 [0x59d86f5e01d5] ``` The optimization in question: https://github.com/ruby/ruby/blob/957c832db137e67289e93dfd9fd9e915b1f2fc87/… Before entering this `newrange` optimization, the iseq looks like this: ``` == disasm: #<ISeq:<compiled>@<compiled>:1 (1,0)-(1,17)> 0000 putchilledstring "a" ( 1)[Li] 0002 dup 0003 branchif 8 0005 pop 0006 putchilledstring "b" 0008 putchilledstring "c" 0010 newrange 0 0012 leave ``` So the optimization constructs a new range using the wrong operands (`"b"` and `"c"` instead of `"a"` and `"c"`). Also, I'm wondering why chilled strings are not ||-peephole-optimized? ``` ruby ruby --dump insn -ve '"a" || "b"' ruby 3.5.0dev (2025-10-19T14:22:25Z master 957c832db1) +PRISM [x86_64-linux] == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 putchilledstring "a" ( 1)[Li] 0002 dup 0003 branchif 8 0005 pop 0006 putchilledstring "b" 0008 leave ``` ```ruby ruby --enable-frozen-string-literal --dump insn -ve '"a" || "b"' ruby 3.5.0dev (2025-10-19T14:22:25Z master 957c832db1) +PRISM [x86_64-linux] == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 putobject "a" ( 1)[Li] 0002 leave ``` ```ruby ruby --disable-frozen-string-literal --dump insn -ve '"a" || "b"' ruby 3.5.0dev (2025-10-19T14:22:25Z master 957c832db1) +PRISM [x86_64-linux] == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 putstring "a" ( 1)[Li] 0002 leave ``` -- https://bugs.ruby-lang.org/

2 1