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

[ruby-core:124359] [Ruby Misc#21804] Getting setup-ruby Earlier
by koic (Koichi ITO) 20 Jan '26

20 Jan '26

Issue #21804 has been reported by koic (Koichi ITO). ---------------------------------------- Misc #21804: Getting setup-ruby Earlier https://bugs.ruby-lang.org/issues/21804 * Author: koic (Koichi ITO) * Status: Open ---------------------------------------- ruby/setup-ruby is commonly used for development in OSS projects and real-world Rails applications. https://github.com/ruby/setup-ruby This is not specific to Ruby 4.0.0. There is often a delay between a Ruby release and the availability of the corresponding version in setup-ruby. setup-ruby is maintained by the ruby organization and may take a few days to become available after a Ruby release. In contrast, ruby-build is maintained by the rbenv organization and tends to become available shortly after a Ruby release. This makes it easier to start using new Ruby versions immediately. If setup-ruby maintained by the ruby organization were released shortly after a Ruby release, users could start using new Ruby versions sooner. It is difficult to determine whether this issue should be registered on bugs.ruby-lang.org. Since setup-ruby is maintained by the ruby organization, this issue is being opened to raise awareness of the situation. If this is not appropriate, please feel free to close it. Thank you for your continued maintenance and for releasing Ruby. -- https://bugs.ruby-lang.org/

9 16

[ruby-core:123920] [Ruby Bug#21715] Miscompilation on x86-64-v2 due to undefined behavior in search_nonascii in string.c
by mjacob (Manuel Jacob) 19 Jan '26

19 Jan '26

Issue #21715 has been reported by mjacob (Manuel Jacob). ---------------------------------------- Bug #21715: Miscompilation on x86-64-v2 due to undefined behavior in search_nonascii in string.c https://bugs.ruby-lang.org/issues/21715 * Author: mjacob (Manuel Jacob) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Building the following Dockerfile fails on a x86-64 machine in the last step (running `make` command): ``` FROM opensuse/leap:16.0 RUN zypper --non-interactive install wget make gcc RUN wget 'https://cache.ruby-lang.org/pub/ruby/3.4/ruby-3.4.7.tar.gz' RUN tar xaf ruby-3.4.7.tar.gz WORKDIR ruby-3.4.7/build RUN ../configure RUN make ``` The failing command (during `make`) is: `./miniruby -I../lib -I. -I.ext/common ../tool/mkconfig.rb -arch=x86_64-linux -version=3.4.7 -install_name=ruby -so_name=ruby -unicode_version=15.0.0 -unicode_emoji_version=15.0 > rbconfig.tmp` Excerpt from the crash report: ``` ../tool/mkconfig.rb: [BUG] Segmentation fault at 0x0000000000000000 ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:0000 s:0003 E:000ec0 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- Machine register context ------------------------------------------------ RIP: 0x0000556c2da74760 RBP: 0x0000000000000027 RSP: 0x00007ffd24a195f0 RAX: 0x0000000000000028 RBX: 0x0000556c64acc420 RCX: 0x0000000000000000 RDX: 0x0000000000000000 RDI: 0x0000000000000014 RSI: 0x00007f49f7d6c123 R8: 0x46ea57707c6b1df2 R9: 0x00007f49f7d6c123 R10: 0x2afb945fcb545f01 R11: 0x0000556c2dc3fe50 R12: 0x00007f49f7d6c263 R13: 0x00007f49f7d6c11b R14: 0x0000556c64bdaa48 R15: 0x00007f49f7d6c25c EFL: 0x0000000000010256 -- C level backtrace information ------------------------------------------- /ruby-3.4.7/build/miniruby(rb_print_backtrace+0x5) [0x556c2db2c1b6] ../vm_dump.c:823 /ruby-3.4.7/build/miniruby(rb_vm_bugreport) ../vm_dump.c:1155 /ruby-3.4.7/build/miniruby(rb_bug_for_fatal_signal+0xf7) [0x556c2d8cdc47] ../error.c:1130 /ruby-3.4.7/build/miniruby(sigsegv+0x42) [0x556c2da58482] ../signal.c:934 /lib64/libc.so.6(__restore_rt+0x0) [0x7f49f7eb2090] /ruby-3.4.7/build/miniruby(search_nonascii+0xcb) [0x556c2da74760] ../string.c:729 /ruby-3.4.7/build/miniruby(coderange_scan) ../string.c:767 /ruby-3.4.7/build/miniruby(rbimpl_fl_unset_raw_raw+0x0) [0x556c2da76874] ../string.c:895 /ruby-3.4.7/build/miniruby(RB_FL_UNSET_RAW) ../include/ruby/internal/fl_type.h:669 /ruby-3.4.7/build/miniruby(RB_ENC_CODERANGE_SET) ../include/ruby/internal/encoding/coderange.h:131 /ruby-3.4.7/build/miniruby(enc_coderange_scan) ../string.c:911 /ruby-3.4.7/build/miniruby(rb_enc_str_coderange) ../string.c:910 /ruby-3.4.7/build/miniruby(is_ascii_string+0x8) [0x556c2da7697e] ../internal/string.h:151 /ruby-3.4.7/build/miniruby(str_do_hash) ../string.c:393 /ruby-3.4.7/build/miniruby(register_fstring) ../string.c:554 /ruby-3.4.7/build/miniruby(rb_enc_literal_str+0x87) [0x556c2da94bb7] ../string.c:12546 /ruby-3.4.7/build/miniruby(parse_static_literal_string+0x38) [0x556c2d875991] ../prism_compile.c:312 /ruby-3.4.7/build/miniruby(pm_compile_node) ../prism_compile.c:10321 /ruby-3.4.7/build/miniruby(pm_compile_node+0x2e65) [0x556c2d875aa5] ../prism_compile.c:10309 /ruby-3.4.7/build/miniruby(pm_compile_conditional+0x18c) [0x556c2d88cfcc] ../prism_compile.c:1053 /ruby-3.4.7/build/miniruby(pm_compile_node+0x42e1) [0x556c2d876f21] ../prism_compile.c:9355 /ruby-3.4.7/build/miniruby(pm_setup_args_core+0xe4) [0x556c2d884304] ../prism_compile.c:1792 /ruby-3.4.7/build/miniruby(pm_setup_args+0x98) [0x556c2d884e98] ../prism_compile.c:1979 /ruby-3.4.7/build/miniruby(pm_compile_call+0x307) [0x556c2d885cf7] ../prism_compile.c:3673 /ruby-3.4.7/build/miniruby(pm_compile_call_node+0x2c6) [0x556c2d872326] ../prism_compile.c:7403 /ruby-3.4.7/build/miniruby(pm_compile_node+0x39dc) [0x556c2d87661c] ../prism_compile.c:8775 /ruby-3.4.7/build/miniruby(pm_compile_node+0x2e65) [0x556c2d875aa5] ../prism_compile.c:10309 /ruby-3.4.7/build/miniruby(pm_compile_conditional+0x18c) [0x556c2d88cfcc] ../prism_compile.c:1053-march=x86-64-v2 /ruby-3.4.7/build/miniruby(pm_compile_node+0x42e1) [0x556c2d876f21] ../prism_compile.c:9355 /ruby-3.4.7/build/miniruby(pm_compile_node+0x2e3a) [0x556c2d875a7a] ../prism_compile.c:10307 /ruby-3.4.7/build/miniruby(pm_compile_scope_node+0x104a) [0x556c2d88f5da] ../prism_compile.c:6991 /ruby-3.4.7/build/miniruby(pm_compile_node+0x35c9) [0x556c2d876209] ../prism_compile.c:10180 /ruby-3.4.7/build/miniruby(APPEND_LIST+0x0) [0x556c2d891e60] ../prism_compile.c:10481 /ruby-3.4.7/build/miniruby(pm_iseq_compile_node) ../prism_compile.c:10485 /ruby-3.4.7/build/miniruby(pm_iseq_new_with_opt_try+0x10) [0x556c2d94c790] ../iseq.c:1042 /ruby-3.4.7/build/miniruby(rb_protect+0xd6) [0x556c2d8db9c6] ../eval.c:1054 /ruby-3.4.7/build/miniruby(pm_iseq_new_with_opt+0x177) [0x556c2d9525c7] ../iseq.c:1095 /ruby-3.4.7/build/miniruby(pm_iseq_new_main+0x85) [0x556c2d952895] ../iseq.c:943 /ruby-3.4.7/build/miniruby(process_options+0x12fd) [0x556c2da519cd] ../ruby.c:2616 /ruby-3.4.7/build/miniruby(ruby_process_options+0x157) [0x556c2da52657] ../ruby.c:3174 /ruby-3.4.7/build/miniruby(ruby_options+0x97) [0x556c2d8da977] ../eval.c:117 /ruby-3.4.7/build/miniruby(rb_main+0x19) [0x556c2d7eb578] ../prism/prism.c:21769 /ruby-3.4.7/build/miniruby(main) ../main.c:68 /lib64/libc.so.6(__libc_start_call_main+0x82) [0x7f49f7e9b340] /lib64/libc.so.6(__libc_start_main+0x8b) [0x7f49f7e9b409] /ruby-3.4.7/build/miniruby(_start+0x25) [0x556c2d7eb5c5] ../main.c:69 ``` The failing instruction at 0x556c2da74760 is: `movdqa xmm0, XMMWORD PTR [rsi+rcx*1]`. At this place, register `rsi` contains 0x7f49f7d6c123, which is the value 0x7f49f7d6c11b of parameter `p` of the function `search_nonascii` + 8, and register `rcx` contains 0. So, the whole instruction means “[move aligned packed integer values](https://www.felixcloutier.com/x86/movdqa:vmovdqa32:vmovdqa64) from memory at 0x7f49f7d6c123 to register `xmm0`”. The segmentation fault happened because the address is expected to be aligned on a 16-byte boundary, but it is not. The instruction is part of a loop at https://github.com/ruby/ruby/blob/v3_4_7/string.c#L728 that gets auto-vectorized by GCC. On x86-64, * `UNALIGNED_WORD_ACCESS` is `1` * `p` doesn’t get aligned to anything because of `#if !UNALIGNED_WORD_ACCESS` in line 700 * `aligned_ptr(value)` is expanded to `(uintptr_t *)(value)` according to line 723 * `p` is therefore casted to type `uintptr_t *` in line 725 * `uintptr_t` is typedefed to `unsigned long int`, which has alignment of 8 bytes In result, a pointer `p` to potentially unaligned memory is casted to a pointer to a type with alignment of 8 bytes. That is undefined behavior according to C99 6.3.2.3p7: “A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the pointed-to type, the behavior is undefined.”. Compilers can utilize this rule to make the assumption that the pointed-to memory has alignment of 8 bytes. In this case, the GCC loop auto-vectorizer adds code to align the assumedly 8 bytes aligned address to 16 bytes alignment. A subsequent instruction assuming 16 bytes alignment can therefore fail. I could reproduce this crash only on openSUSE Leap 16.0, but not openSUSE Leap 15.6, openSUSE Tumbleweed or Arch Linux, because only the former configured GCC to default to emitting code requiring x86-64-v2. When passing `-march=x86-64-v2` in CFLAGS, the crash happens on all these distributions. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:124311] [Ruby Feature#21795] Methods for retrieving ASTs
by kddnewton (Kevin Newton) 16 Jan '26

16 Jan '26

Issue #21795 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I would like to propose a handful of methods for retrieving ASTs from various objects that correspond to locations in code. This includes: * Proc#ast * Method#ast * UnboundMethod#ast * Thread::Backtrace::Location#ast * TracePoint#ast (on call/return events) The purpose of this is to make tooling easier to write and maintain. Specifically, this would be able to be used in irb, power_assert, error_highlight, and various other tools both in core and not that make use of source code. There have been many previous discussions of retrieving node_id, source_location, source, etc. All of these use cases are covered by returning the AST for some entity. In this case node_id becomes an implementation detail, invisible to the user. Source location can be derived from the information on the AST itself. Similarly, source can be derived from the AST. Internally, I do not think we have to store any more information than we already do (since we have node_id for the first four of these, it becomes rather trivial). For TracePoint we can have a larger discussion about it, but I think it should not be too much work. In terms of implementation, the only caveat I would put is that if the ISEQ were compiled through the old parser/compiler, this should return `nil`, as the node ids do not match up and we do not want to further propagate the RubyVM::AST API. The reason I am opening up this ticket with 5 different methods requested in it is to get approval first for the direction, then I can open individual tickets or just PRs for each method. I believe this feature would ease the maintenance burden of many core libraries, and unify otherwise disparate efforts to achieve the same thing. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:124408] [Ruby Bug#21816] iseq code_location miss calculated indent
by zzak (zzak _) 16 Jan '26

16 Jan '26

Issue #21816 has been reported by zzak (zzak _). ---------------------------------------- Bug #21816: iseq code_location miss calculated indent https://bugs.ruby-lang.org/issues/21816 * Author: zzak (zzak _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- TBH, I'm not really sure if that title matches the problem here, but I can produce this issue with the following test: ```ruby # bug.rb # note the indentation of the callable callable = -> { puts "Hello, World!" } iseq = RubyVM::InstructionSequence.of(callable) pp iseq.to_a pp iseq.to_a[4] pp iseq.to_a[4][:code_location][1] ``` Ruby 4.0.0: ``` $ ruby -v bug.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] ["YARVInstructionSequence/SimpleDataFormat", 4, 0, 1, {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 15, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism}, "block in <main>", "bug.rb", "/tmp/tmp.Fbq5WA0GnO/bug.rb", 1, :block, [], {}, [], [1, :RUBY_EVENT_LINE, :RUBY_EVENT_B_CALL, [:putself], [:putchilledstring, "Hello, World!"], [:opt_send_without_block, {mid: :puts, flag: 20, orig_argc: 1}], :RUBY_EVENT_B_RETURN, [:leave]]] {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 15, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism} 15 ``` Ruby 4.1.0: ``` $ ruby -v bug.rb ruby 4.1.0dev (2025-12-30T18:02:00Z master 9d37155cfc) +PRISM [x86_64-linux] ["YARVInstructionSequence/SimpleDataFormat", 4, 1, 1, {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 13, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism}, "block in <main>", "bug.rb", "/tmp/tmp.Fbq5WA0GnO/bug.rb", 1, :block, [], {}, [], [1, :RUBY_EVENT_LINE, :RUBY_EVENT_B_CALL, [:putself], [:putchilledstring, "Hello, World!"], [:opt_send_without_block, {mid: :puts, flag: 20, orig_argc: 1}], :RUBY_EVENT_B_RETURN, [:leave]]] {arg_size: 0, local_size: 0, stack_max: 2, node_id: 7, code_location: [1, 13, 1, 40], node_ids: [4, 5, 4, 7], parser: :prism} 13 ``` For context: This second value being 13 instead of 15 is causing Rails tests to fail: https://buildkite.com/rails/rails-nightly/builds/3447#019b710f-e78a-405f-82… We want: ``` { @object.num } ``` But we get: ``` -> { @object.num } ``` I am pretty sure using the same version of `prism`: ``` /tmp/tmp.Fbq5WA0GnO => rbenv shell 4.1.0 /tmp/tmp.Fbq5WA0GnO => gem list | grep prism prism (1.7.0) /tmp/tmp.Fbq5WA0GnO => rbenv shell 4.0.0 /tmp/tmp.Fbq5WA0GnO => gem list | grep prism prism (1.7.0) ``` We use this data to get the original source string of a block we use to decorate the `assert_difference` assertion: https://github.com/rails/rails/blob/3d31d593e6cf0f82fa9bd0338b635af2f30d627… https://api.rubyonrails.org/classes/ActiveSupport/Testing/Assertions.html#m… -- https://bugs.ruby-lang.org/

4 5

[ruby-core:124054] [Ruby Misc#21768] Remove deprecated functions
by nobu (Nobuyoshi Nakada) 16 Jan '26

16 Jan '26

Issue #21768 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Misc #21768: Remove deprecated functions https://bugs.ruby-lang.org/issues/21768 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123966] [Ruby Bug#21723] `binding.irb` raises a LoadError under `bundle exec`
by osyoyu (Daisuke Aritomo) 16 Jan '26

16 Jan '26

Issue #21723 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Bug #21723: `binding.irb` raises a LoadError under `bundle exec` https://bugs.ruby-lang.org/issues/21723 * Author: osyoyu (Daisuke Aritomo) * Status: Open * ruby -v: ruby 4.0.0preview2 (2025-11-17 master 4fa6e9938c) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In Ruby 4.0, `binding.irb` raises a LoadError when some unknown condition is met. ```ruby # main.rb binding.irb ``` ``` main.rb:1: warning: irb used to be loaded from the standard library, but is not part of the default gems since Ruby 4.0.0. You can add irb to your Gemfile or gemspec to fix this error. Failed to activate irb, please install it with 'gem install irb' /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'Kernel.require': cannot load such file -- irb (LoadError) Did you mean? erb from /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'block (2 levels) in Kernel#replace_require' from main.rb:1:in 'Binding#irb' from main.rb:1:in '<main>' /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'Kernel.require': cannot load such file -- irb (LoadError) Did you mean? erb from /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'block (2 levels) in Kernel#replace_require' from main.rb:1:in 'Binding#irb' from main.rb:1:in '<main>' ``` While irb has been changed to a bundle gem in #20309, it is agreed that `binding.irb` shall work under `bundle exec` without adding `irb` in Gemfile. Thus, I've considered this behavior as an bug and created a ticket here. One condition I have discovered is when the Gemfile contains a `gem` reference with a `path:` option. I have created a repro repository in https://github.com/osyoyu/irbfail for that case. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:124047] [Ruby Feature#21766] Pathname + FileUtils making sweet music together
by gurgeous (Adam Doppelt) 16 Jan '26

16 Jan '26

Issue #21766 has been reported by gurgeous (Adam Doppelt). ---------------------------------------- Feature #21766: Pathname + FileUtils making sweet music together https://bugs.ruby-lang.org/issues/21766 * Author: gurgeous (Adam Doppelt) * Status: Open ---------------------------------------- I love Pathname. I love FileUtils. Let's bring these two classes EVEN CLOSER TOGETHER by adding some tragically missing helpers. Something like this, perhaps? ``` ruby class Pathname def mkdir_p(...) = FileUtils.mkdir_p(@path, ...) def ln(...) = FileUtils.ln(@path, ...) def ln_s(...) = FileUtils.ln_s(@path, ...) def ln_sf(...) = FileUtils.ln_sf(@path, ...) def cp(...) = FileUtils.cp(@path, ...) def cp_r(...) = FileUtils.cp_r(@path, ...) def mv(...) = FileUtils.mv(@path, ...) def rm(...) = FileUtils.rm(@path, ...) def rm_r(...) = FileUtils.rm_r(@path, ...) def rm_rf(...) = FileUtils.rm_rf(@path, ...) end ``` There are some concerns about making pathname.rb more dependent on FileUtils, which I understand. What's the best way forward? Let's do it! (also see https://github.com/ruby/pathname/issues/64 and https://github.com/ruby/pathname/issues/72) -- https://bugs.ruby-lang.org/

5 6

[ruby-core:124342] [Ruby Feature#21800] `Dir.foreach` and `Dir.each_child` to optionally yield `File::Stat` object alongside the children name
by byroot (Jean Boussier) 15 Jan '26

15 Jan '26

Issue #21800 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21800: `Dir.foreach` and `Dir.each_child` to optionally yield `File::Stat` object alongside the children name https://bugs.ruby-lang.org/issues/21800 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- When listing a directory, it's very common to need to know the type of each children, generally because you want to scan recursively. The naive way to do this is to call `stat(2)` for each children, but this is quite costly. This use case is common enough that `readdir` on most modern platforms do expose `struct dirent.d_type`, which allows to know the type of the child without an extra syscall. I wrote a quick prototype, and relying on `dirent.d_type` instead of `stat(2)` allows to recursively scan Ruby's repository twice as fast on my machine: https://github.com/ruby/ruby/pull/15667 Given that recursively scanning directories is a common task across many popular ruby tools (`zeitwerk`, `rubocop`, etc), I think it would be very valuable to provide this more efficient interface. In addition, @nobu noticed my prototype, and implemented a nicer version of it, where a `File::Stat` is yielded: https://github.com/ruby/ruby/commit/9acf67057b9bc6f855b2c37e41c1a2f91eae643a In that case the `File::Stat` is lazy, it's only if you access something other than file type, that the actual `stat(2)` call is emitted. I think this API is both more efficient and more convenient. ### Proposed API ```ruby Dir.foreach(path) { |name| } Dir.foreach(path) { |name, stat| } Dir.each_child(path) { |name| } Dir.each_child(path) { |name| } Dir.new(path).each_child { |name, stat| } Dir.new(path).each_child { |name, stat| } Dir.new(path).each { |name, stat| } Dir.new(path).each { |name, stat| } ``` Also important to note, the `File::Stat` is expected to be equivalent to a `lstat(2)` call, as to be able to chose to follow symlinks or not. Basic use case: ```ruby def count_ruby_files(root) count = 0 queue = [root] while dir = queue.pop Dir.(dir) do |name, stat| next if name.start_with?(".") if stat.directory? queue << File.join(dir, name) elsif stat.file? count += 1 if name.end_with?(".rb") end end end count end ``` -- https://bugs.ruby-lang.org/

4 8

[ruby-core:124278] [Ruby Feature#21788] Promote Thread::Monitor to a core class
by byroot (Jean Boussier) 14 Jan '26

14 Jan '26

Issue #21788 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21788: Promote Thread::Monitor to a core class https://bugs.ruby-lang.org/issues/21788 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- `Monitor` is about as useful as `Mutex` and yet one is a core class and the other is a "stdlib" extension. I propose to promote `Thread::Monitor` as a core class convenience. ### The rest of `monitor.rb` The `monitor` stdlib also contains `MonitorMixin`, but I think this part can remain in `lib/monitor.rb` (or even be moved to `lib/monitor_mixin.rb`. One more questionable part is `Monitor#new_cond`, as it returns a `::MonitorMixin::ConditionVariable` so it would also need to remain in the stdlib. ### Performance benefit By being a core class, Monitor can also be implemented more efficiently, as it is no longer constrained to the public C API. On my branch, monitor is approximately 15% faster (but there might be some more optimizations to be found). `master`: ``` ruby 4.0.0dev (2025-12-17T07:21:34Z core-monitor 32815a1bc4) +YJIT +PRISM [arm64-darwin25] Warming up -------------------------------------- Mutex 1.975M i/100ms Monitor 1.936M i/100ms Calculating ------------------------------------- Mutex 25.213M (± 0.4%) i/s (39.66 ns/i) - 126.407M in 5.013728s Monitor 24.099M (± 0.1%) i/s (41.50 ns/i) - 121.992M in 5.062092s ``` core monitor: ``` ruby 4.0.0dev (2025-12-17T07:16:32Z master 54d3945ee5) +YJIT +PRISM [arm64-darwin25] Warming up -------------------------------------- Mutex 1.952M i/100ms Monitor 1.775M i/100ms Calculating ------------------------------------- Mutex 25.102M (± 0.4%) i/s (39.84 ns/i) - 126.884M in 5.054731s Monitor 21.189M (± 0.1%) i/s (47.19 ns/i) - 106.485M in 5.025493s ``` Proposed implementation: https://github.com/ruby/ruby/pull/15538 -- https://bugs.ruby-lang.org/

4 6

[ruby-core:124385] [Ruby Feature#21813] Add [:forward, :...] symbol tuple to indicate forwarding arguments when calling `Method#parameters`
by pabloh (Pablo Herrero) 14 Jan '26

14 Jan '26

Issue #21813 has been reported by pabloh (Pablo Herrero). ---------------------------------------- Feature #21813: Add [:forward, :...] symbol tuple to indicate forwarding arguments when calling `Method#parameters` https://bugs.ruby-lang.org/issues/21813 * Author: pabloh (Pablo Herrero) * Status: Open ---------------------------------------- When accessing `Method#parameters` for a method using forwarding parameters, an unexpected behavior arises: ``` def foo(*, **, &) "puts(#{(method(__method__).parameters.dig(0,1))})" # Fails! end def foo(...) "puts(#{(method(__method__).parameters.dig(0,1))})" # Works fine end ``` It's very strange that you can't access the parameters, on `eval`, using the symbols provided at `Method#parameters`. Adding `[:forward, :...]` or `[:forwarding, :...]` for those cases feels simply natural. -- https://bugs.ruby-lang.org/

2 2