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

[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) 06 Nov '25

06 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

[ruby-core:123146] [Ruby Bug#21559] Unicode normalization nfd -> nfc -> nfd is not reversible
by tompng (tomoya ishida) 03 Nov '25

03 Nov '25

Issue #21559 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21559: Unicode normalization nfd -> nfc -> nfd is not reversible https://bugs.ruby-lang.org/issues/21559 * Author: tompng (tomoya ishida) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I expect `nfd(nfc(str)) == nfd(str)` but found a string that doesn't. ~~~ruby # Ruby 3.1 - 3.5 str = "s\u{11930}\u{323}\u{11930}\u{307}" p str.unicode_normalize(:nfd) == str.unicode_normalize(:nfc).unicode_normalize(:nfd) #=> false ~~~ ~~~ruby # ruby 3.5.0dev str = "s\u{1611e}\u{323}\u{1611e}\u{307}\u{1611f}" p str.unicode_normalize(:nfd) == str.unicode_normalize(:nfc).unicode_normalize(:nfd) #=> false ~~~ -- https://bugs.ruby-lang.org/

4 7

[ruby-core:123172] [Ruby Bug#21560] RUBY_MN_THREADS=1 causes large performance regression in Puma 7
by schneems (Richard Schneeman) 02 Nov '25

02 Nov '25

Issue #21560 has been reported by schneems (Richard Schneeman). ---------------------------------------- Bug #21560: RUBY_MN_THREADS=1 causes large performance regression in Puma 7 https://bugs.ruby-lang.org/issues/21560 * Author: schneems (Richard Schneeman) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ## Expected Running a webserver with `RUBY_MN_THREADS=1` will increase performance or keep it the same. ## Actual - Before: 22919.85 Requests/sec - After: 2287.13 Requests/sec ## Reproduction Tracking this at https://github.com/puma/puma/issues/3720. I would like to get a smaller reproduction, but until then here's how we're able to induce the failure: Prepare puma: ``` $ git clone https://github.com/puma/puma $ cd puma $ git checkout v7.0.0.pre1 $ rake compile ``` Boot the server to deliver a "hello world" response: ``` $ bundle exec ruby -Ilib bin/puma -w 1 -t1 --preload test/rackup/hello.ru ``` Exercise the server with `wrk` (brew install wrk): ``` $ wrk -H 'Host: tfb-server' -H 'Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7' -H 'Connection: keep-alive' --latency -d 15 -c 16 --timeout 8 -t 12 http://localhost:9292 ``` ### Results Before: ``` $ bundle exec ruby -Ilib bin/puma -w 1 -t1 --preload test/rackup/hello.ru ``` ``` $ wrk -H 'Host: tfb-server' -H 'Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7' -H 'Connection: keep-alive' --latency -d 15 -c 16 --timeout 8 -t 12 http://localhost:9292 Running 15s test @ http://localhost:9292 12 threads and 16 connections Thread Stats Avg Stdev Max +/- Stdev Latency 786.74us 1.45ms 45.57ms 90.62% Req/Sec 1.92k 188.55 4.20k 83.22% Latency Distribution 50% 386.00us 75% 523.00us 90% 2.11ms 99% 4.63ms 344638 requests in 15.04s, 25.23MB read Requests/sec: 22919.85 Transfer/sec: 1.68MB ``` After: ``` $ env RUBY_MN_THREADS=1 bundle exec ruby -Ilib bin/puma -w 1 -t1 --preload test/rackup/hello.ru ``` ``` $ wrk -H 'Host: tfb-server' -H 'Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7' -H 'Connection: keep-alive' --latency -d 15 -c 16 --timeout 8 -t 12 http://localhost:9292 Running 15s test @ http://localhost:9292 12 threads and 16 connections Thread Stats Avg Stdev Max +/- Stdev Latency 28.89ms 40.82ms 129.37ms 78.94% Req/Sec 207.34 64.09 252.00 70.70% Latency Distribution 50% 212.00us 75% 56.77ms 90% 99.48ms 99% 127.01ms 34365 requests in 15.03s, 2.52MB read Requests/sec: 2287.13 Transfer/sec: 171.45KB ``` (Notice the dramatic drop in requests per second). -- https://bugs.ruby-lang.org/

8 12

[ruby-core:123623] [Ruby Bug#21658] Encoding objects are dumped with an encoding of US-ASCII
by headius (Charles Nutter) 01 Nov '25

01 Nov '25

Issue #21658 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #21658: Encoding objects are dumped with an encoding of US-ASCII https://bugs.ruby-lang.org/issues/21658 * Author: headius (Charles Nutter) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- All encodings get Marshal.dump'ed with an encoding instance variable: ``` $ cx ruby-3.4 ruby -e 'Encoding.constants.each { p Marshal.dump(Encoding.const_get(it)) }' "\x04\bIu:\rEncoding\x10MacJapanese\x06:\x06EF" "\x04\bIu:\rEncoding\x10MacJapanese\x06:\x06EF" "\x04\bIu:\rEncoding\rUS-ASCII\x06:\x06EF" "\x04\bIu:\rEncoding\rUS-ASCII\x06:\x06EF" "\x04\bIu:\rEncoding\x10MacJapanese\x06:\x06EF" "\x04\bIu:\rEncoding\nUTF-7\x06:\x06EF" "\x04\bIu:\rEncoding\nUTF-8\x06:\x06EF" "\x04\bIu:\rEncoding\nUTF-7\x06:\x06EF" ... ``` This despite the fact that an Encoding does not have an encoding: ``` $ cx ruby-3.4 ruby -e 'Encoding::UTF_8.encoding' -e:1:in '<main>': undefined method 'encoding' for an instance of Encoding (NoMethodError) ``` Compare with JRuby output: ``` $ cx jruby-10.0.2.0 ruby -e 'p Marshal.dump(Encoding::UTF_8)' "\x04\bu:\rEncoding\nUTF-8" ``` This extra instance variable data causes the output to be unloadable by JRuby, because an Encoding object cannot itself have an encoding: ``` $ cx jruby-10.0.2.0 ruby -e 'p Marshal.load("\x04\bIu:\rEncoding\nUTF-8\x06:\x06EF")' ArgumentError: UTF-8is not enc_capable load at org/jruby/RubyMarshal.java:165 <main> at -e:1 ``` This is reported as a JRuby issue here: https://github.com/jruby/jruby/issues/9050 Encoding should not marshal with an encoding it does not actually have. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123586] [Ruby Misc#21656] Exclude dependabot PRs from automated gem release notes
by Earlopain (Earlopain _) 31 Oct '25

31 Oct '25

Issue #21656 has been reported by Earlopain (Earlopain _). ---------------------------------------- Misc #21656: Exclude dependabot PRs from automated gem release notes https://bugs.ruby-lang.org/issues/21656 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- Ruby has many gems, and many of them have release notes generated with the github command line instead of being written by a human. Usually that is fine, I don't have much of a problem with that approach. But what is less ideal is that github actions are pinned by commit hash/minor version which causes many dependabot PRs. This results in release notes like this: https://github.com/ruby/timeout/releases/tag/v0.4.4 ``` Bump rubygems/release-gem from 1.1.0 to 1.1.1 by @dependabot[bot] in #56 Bump step-security/harden-runner from 2.10.2 to 2.10.3 by @dependabot[bot] in #57 Bump step-security/harden-runner from 2.10.3 to 2.10.4 by @dependabot[bot] in #59 Bump step-security/harden-runner from 2.10.4 to 2.11.0 by @dependabot[bot] in #60 Bump step-security/harden-runner from 2.11.0 to 2.11.1 by @dependabot[bot] in #61 Bump step-security/harden-runner from 2.11.1 to 2.12.0 by @dependabot[bot] in #62 Bump step-security/harden-runner from 2.12.0 to 2.12.1 by @dependabot[bot] in #63 Gracefully handle a call to ensure_timeout_thread_created in a signal handler by @eregon in #64 Bump step-security/harden-runner from 2.12.1 to 2.12.2 by @dependabot[bot] in #65 Bump step-security/harden-runner from 2.12.2 to 2.13.0 by @dependabot[bot] in #66 Bump actions/checkout from 4 to 5 by @dependabot[bot] in #67 Bump step-security/harden-runner from 2.13.0 to 2.13.1 by @dependabot[bot] in #68 Add a workflow to sync commits to ruby/ruby by @k0kubun in #69 ``` You might have missed it but hidden between all the automated non-user facing PRs is actually something that users might want to read about: `Gracefully handle a call to ensure_timeout_thread_created in a signal handler by @eregon in #64`. I would like these release notes to omit bot PRs since they don't have any impact on gem consumers and only make it hard to actually find what changed. Doing a quick search, 56 gems create release notes in this way: https://github.com/search?q=org%3Aruby+lang%3Ayml+--generate-notes&type=code. Really, I would want these written by a human since even without bot PRs there are still many that are just maintenance to fix CI or similar that don't concern the end user but I can understand that probably no one actually wants to write these by hand, which is why I propose to just exclude bot PRs. That should already have a pretty big impact. -- https://bugs.ruby-lang.org/

4 7

[ruby-core:123350] [Ruby Bug#21618] Allow to use the build-in prism version to parse code
by Earlopain (Earlopain _) 29 Oct '25

29 Oct '25

Issue #21618 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21618: Allow to use the build-in prism version to parse code https://bugs.ruby-lang.org/issues/21618 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism is a multi-version parser, which is a great feature. If one calls `Prism.parse("foo")`, it will always use the latest version prism knows about. This may or may not be the version that is currently executing. This is problematic when one wants to introspect code the same way that the currently running ruby version would. Consider that some syntax will be disallowed in the next ruby version. I would have to specify the ruby version I want to parse as in order to not run into syntax errors: `Prism.parse("foo", version: RUBY_VERSION)`. But doing so is not feasable because `prism` is distributed out of sync with ruby itself. If the user already has prism in their lockfile, the user may run a prism version that doesn't yet know about lets say ruby 4.0 and thus raise. Similarly, it may parse as an older patch version that has subtle behaviour differences. `ripper` does not have this issue because it is always tied to the ruby version and it is not distributed as a gem, so what the user has will always be exactly what ruby shipped with. I wish for a similar API that utilizes the prism version bundled with ruby itself. Libraries like `rails` have moved from ripper to prism because of its superior developer experience but it risks breaking in unexpected ways with new `prism` versions that know about more recent syntax. `error_highlight` for example also suffers from the same defect. It seems like prism currently has 34 methods that optionally take a version (per the rbi file). Many of these are trivial helper methods like `Prism.parse_success?` (does the parse result have any errors?). I would be happy with supporting only the minimal functions like `Prism.parse` and `Prism.parse_file`. Currently I don't have a use-case for any of the other methods. Pretty much just functions to mirror `RubyVM::InstructionSequence.compile_file` and `RubyVM::InstructionSequence.compile`. It would be optimal if I would be able to transparently call `Prism.parse("foo", version: "current")` (or maybe even have an unspecified version mean the build-in prism version) but I am not sure how feasable that is since I'm pretty sure logic for this would have to live in ruby itself. @kddnewton does this feature request make sense? Do you have any other ideas/inputs? -- https://bugs.ruby-lang.org/

4 14