January 2026 - ruby-core - ml.ruby-lang.org

[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) 13 Feb '26

13 Feb '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/

5 10

[ruby-core:123433] [Ruby Misc#21630] Suggest @Earlopain for core contributor
by kddnewton (Kevin Newton) 12 Feb '26

12 Feb '26

Issue #21630 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #21630: Suggest @Earlopain for core contributor https://bugs.ruby-lang.org/issues/21630 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- @Earlopain has been prolifically contributing to Prism for over a year, in addition to other various changes around ruby/ruby, like [96fdaf2e](https://github.com/ruby/ruby/commit/96fdaf2e393933fdd128cd1a41fa9…, [3826019f](https://github.com/ruby/ruby/commit/3826019f310991aedf0612408d7b8…, [a82e7132](https://github.com/ruby/ruby/commit/a82e7132df71bd99b5d02c0c8a348…, and [many more](https://github.com/ruby/ruby/commits/master/?author=Earlopain). I would very much like @Earlopain to be able to merge their own contributions to Ruby, since they have been of such high quality for so long. -- https://bugs.ruby-lang.org/

8 9

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

12 Feb '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/

3 3

[ruby-core:124367] [Ruby Bug#21808] Inconsistency in support of additional newlines with boolean logical operators on new line
by herwin (Herwin W) 12 Feb '26

12 Feb '26

Issue #21808 has been reported by herwin (Herwin W). ---------------------------------------- Bug #21808: Inconsistency in support of additional newlines with boolean logical operators on new line https://bugs.ruby-lang.org/issues/21808 * Author: herwin (Herwin W) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- With this I mean the new Ruby 4 feature. With the old style, one could add additional lines in between: ```ruby if true && true puts 'match' end ``` With the new style, this results in a syntax error ```ruby if true && true puts 'match' end ``` If a comment is used instead of a new line, it still works ```ruby if true # blah && true puts 'match' end ``` This happens with both prism and parse.y I doubt anyone would want to write code like this (I don't think it improves the layout), but it's still a weird inconsistency that doesn't get mentioned. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:124594] [Ruby Bug#21844] Inconsistent ArgumentError message for Data::define.new
by jnchito (Junichi Ito) 12 Feb '26

12 Feb '26

Issue #21844 has been reported by jnchito (Junichi Ito). ---------------------------------------- Bug #21844: Inconsistent ArgumentError message for Data::define.new https://bugs.ruby-lang.org/issues/21844 * Author: jnchito (Junichi Ito) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The code below shows `Data::define.new` treats symbol and string keys equivalently: ``` ruby C = Data.define(:a, :b) C.new(a: 1, b: 1) #=> #<data C a=1, b=1> C.new('a' => 1, 'b' => 1) #=> #<data C a=1, b=1> ``` But it acts differently when detecting missing keywords: ```ruby C.new(a: 1) #=> 'Data#initialize': missing keyword: :b (ArgumentError) C.new('a' => 1) #=> 'Data#initialize': missing keywords: :a, :b (ArgumentError) ``` I feel it should work like this: ```ruby C.new('a' => 1) #=> 'Data#initialize': missing keyword: :b (ArgumentError) ``` I created a PR to fix it: https://github.com/ruby/ruby/pull/15910 -- https://bugs.ruby-lang.org/

4 10

[ruby-core:124312] [Ruby Feature#21796] unpack variant that returns the final offset
by nobu (Nobuyoshi Nakada) 12 Feb '26

12 Feb '26

Issue #21796 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #21796: unpack variant that returns the final offset https://bugs.ruby-lang.org/issues/21796 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- mame (Yusuke Endoh) wrote in #note-4: > It's a shame `unpack` doesn't tell you how many bytes it read. You'd probably want a `unpack` variant that returns the final offset too, or a specifier that returns the current offset (like `o`?). > > ```ruby > bytes = "\x01\x02\x03" > offset = 0 > leb128_value1, offset = bytes.unpack("Ro", offset: offset) #=> 1 > leb128_value2, offset = bytes.unpack("Ro", offset: offset) #=> 2 > leb128_value3, offset = bytes.unpack("Ro", offset: offset) #=> 3 > ``` mame (Yusuke Endoh) wrote in #note-6: > > You could tell how many bytes you read based on the size of the leb128_value returned. > > That apparoach is unreliable because LEB128 is redundant. For example, both `"\x03"` and `"\x83\x00"` are valid LEB128 encodings of the value 3. > See the note of the section Values - Integers, in the Wasm spec. > https://webassembly.github.io/spec/core/binary/values.html#integers -- https://bugs.ruby-lang.org/

4 6

[ruby-core:124258] [Ruby Feature#21785] Add signed and unsigned LEB128 support to pack / unpack
by tenderlovemaking (Aaron Patterson) 12 Feb '26

12 Feb '26

Issue #21785 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21785: Add signed and unsigned LEB128 support to pack / unpack https://bugs.ruby-lang.org/issues/21785 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Hi, I'd like to add signed and unsigned LEB128 support to the pack and unpack methods. LEB128 is a variable length encoding scheme for integers. You can read the wikipedia entry about it here: https://en.wikipedia.org/wiki/LEB128 LEB128 is used in DWARF, WebAssembly, MQTT, and Protobuf. I'm sure there are other formats, but these are the ones I'm familiar with. I sent a pull request here: https://github.com/ruby/ruby/pull/15589 I'm proposing `K` for the unsigned version and `k` for the signed version. I just picked `k` because it was available, I'm open to other format strings. Thanks for consideration! -- https://bugs.ruby-lang.org/

3 10

[ruby-core:123449] [Ruby Bug#21633] A `rb_thread_call_without_gvl` loop can cause the fiber scheduler to ignore signals.
by ioquatix (Samuel Williams) 12 Feb '26

12 Feb '26

Issue #21633 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21633: A `rb_thread_call_without_gvl` loop can cause the fiber scheduler to ignore signals. https://bugs.ruby-lang.org/issues/21633 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- The gRPC gem calls `rb_thread_call_without_gvl` in a loop, and doesn't exit when interrupts are delivered if `Thread.handle_interrupt(::SignalException => :never)` is used by the scheduler to create a safe point for asynchronous signal handling. While this may not be considered a bug in any particular part of the system, the combination of the behaviour creates a situation where gRPC can hang for a long time and ignores SIGINT / SIGTERM. ## gRPC Failure Analysis From [`src/ruby/ext/grpc/rb_completion_queue.c`](https://github.com/samuel-williams-shopify/grpc/blob/debug/src/ruby/ext/grpc/rb_completion_queue.c): ```c static void unblock_func(void* param) { next_call_stack* const next_call = (next_call_stack*)param; next_call->interrupted = 1; // ← SIGINT causes this flag to be set } grpc_event rb_completion_queue_pluck(grpc_completion_queue* queue, void* tag, gpr_timespec deadline, const char* reason) { // ... do { next_call.interrupted = 0; // ← Reset flag rb_thread_call_without_gvl(grpc_rb_completion_queue_pluck_no_gil, (void*)&next_call, unblock_func, (void*)&next_call); if (next_call.event.type != GRPC_QUEUE_TIMEOUT) break; } while (next_call.interrupted); // ← The problem! If interrupted, LOOP AGAIN! return next_call.event; } ``` The loop explicitly retries after interruption, making SIGINT/SIGTERM ineffective. This might be considered the expected behaviour if `Thread.handle_interrupt` is used. However, the goal of `Thread.handle_interrupt` in the fiber scheduler is to create a safe point for signal handling, not to prevent them completely. Since this loop never yields back to the scheduler, no such chance exists, and the loop will continue indefinitely. As `rb_thread_call_without_gvl` invokes `vm_check_ints_blocking`, one solution is to yield to the scheduler in the case that there are pending interrupts. This gives the scheduler a chance to handle the incoming SIGINT / SIGTERM signals at the safe point. For a full reproduction of the issue using gRPC: https://github.com/samuel-williams-shopify/grpc-interrupt For the proposed fix: https://github.com/ruby/ruby/pull/14700 -- https://bugs.ruby-lang.org/

1 1

[ruby-core:124553] [Ruby Misc#21839] DevMeeting-2026-02-12
by mame (Yusuke Endoh) 12 Feb '26

12 Feb '26

Issue #21839 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21839: DevMeeting-2026-02-12 https://bugs.ruby-lang.org/issues/21839 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/02/12 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 2026/02/09. 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/

10 11

[ruby-core:124631] [Ruby Bug#21851] Performance difference between / operator and fdiv
by mbrown1intel (Michael Brown) 11 Feb '26

11 Feb '26

Issue #21851 has been reported by mbrown1intel (Michael Brown). ---------------------------------------- Bug #21851: Performance difference between / operator and fdiv https://bugs.ruby-lang.org/issues/21851 * Author: mbrown1intel (Michael Brown) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Benchmarking fdiv against the / operator, it seems like fdiv is significantly slower. As far as I'm aware there's no functional difference between these two methods. I first ran this on 2.6, and then checked against 4.0 to make sure it hadn't been fixed in the meantime, and saw the same results. ``` ruby require 'benchmark' n = 500_000_000 c = nil Benchmark.bm do |benchmark| benchmark.report("to_f ") do n.times do |i| c = n / i.to_f end end benchmark.report("fdiv ") do n.times do |i| c = n.fdiv(i) end end end ``` ``` user system total real to_f 37.672000 0.110000 37.782000 ( 38.714876) fdiv 113.016000 0.265000 113.281000 (116.428442) ``` -- https://bugs.ruby-lang.org/

4 4