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:124646] [Ruby Bug#21855] Bundle `win32-registry` or implement it without `fiddle`
by Earlopain (Earlopain _) 13 Feb '26

13 Feb '26

Issue #21855 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21855: Bundle `win32-registry` or implement it without `fiddle` https://bugs.ruby-lang.org/issues/21855 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `win32-registry` (a default gem), is currently implemented via `fiddle` (a bundled gem). This makes it impossible to use under bundler without adding `fiddle` to the gemfile. In the past it has lead to issues like https://bugs.ruby-lang.org/issues/21645. It was solved by simply not using `win32-registry` anymore in `resolv` and implementing it via C (https://github.com/ruby/resolv/pull/110) although the overarching issue is still present. There is also a report for this for rubygems https://github.com/ruby/rubygems/issues/9277. This should be solved by updating the vendored `resolv` version I think. Still, the dependecy relation between `win32-registry` and `fiddle` is pretty incompatible. A default gem can't depend on a bundled gem without breaking dependency resolution. To solve this it would have to be implemented without using `fiddle`, similar to how `resolv` did it. But now that `resolv` doesn't use `win32-registry`, I don't think anything in ruby uses it anymore. So moving it to a bundled gem could also be a solution without rewriting the whole thing. Here is an issue about this in the `win32-registry` repo: https://github.com/ruby/win32-registry/issues/11 -- https://bugs.ruby-lang.org/

3 2

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

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

[ruby-core:124497] [Ruby Feature#21835] Unbundle bunled gems like net-ftp
by hsbt (Hiroshi SHIBATA) 12 Feb '26

12 Feb '26

Issue #21835 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21835: Unbundle bunled gems like net-ftp https://bugs.ruby-lang.org/issues/21835 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- I would like to unundle the following bundled gems: * net-ftp * net-pop * prime The main purpose of bundled gems is to ensure their functionality by running tests with ruby head every time. However, the above gems for older protocols or purposes should be handled the same as other regular gems. -- https://bugs.ruby-lang.org/

1 2

[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:124198] [Ruby Feature#21781] Add `fetch_values` method on `ENV`
by Earlopain (Earlopain _) 12 Feb '26

12 Feb '26

Issue #21781 has been reported by Earlopain (Earlopain _). ---------------------------------------- Feature #21781: Add `fetch_values` method on `ENV` https://bugs.ruby-lang.org/issues/21781 * Author: Earlopain (Earlopain _) * Status: Open ---------------------------------------- In https://bugs.ruby-lang.org/issues/10017, `fetch_values` was introduced for `Hash`. `ENV` is hash-like but is missing the method. Here are the differences between hash and env right now: ```rb irb(main):006> Hash.instance_methods - ENV.methods => [:merge, :compare_by_identity, :compare_by_identity?, :>=, :deconstruct_keys, :dig, :<=, :>, :<, :to_proc, :flatten, :compact!, :default=, :default_proc, :default_proc=, :default, :transform_keys, :transform_keys!, :transform_values!, :fetch_values, :transform_values] ``` `flatten`/`dig` among others make no sense for `ENV`. Some I don't see why they are not present but I won't argue for them since I have no use-case. Here is code I wanted to write: ```rb # Get many env variables and crash if one is missing user, pass, year, target_dir = ENV.fetch_values("USER", "PASS", "YEAR", "TARGET_DIR") ``` For now I am simply adding `to_h` and all is good. But should I have to? Ignoring a small amount of methods, ENV is very close to a hash already. -- https://bugs.ruby-lang.org/

2 2

[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