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

[ruby-core:124461] [Ruby Bug#21830] Ruby::Box and Kernel#require
by fxn (Xavier Noria) 15 Feb '26

15 Feb '26

Issue #21830 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21830: Ruby::Box and Kernel#require https://bugs.ruby-lang.org/issues/21830 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- If you enable `Ruby::Box`, decorations to `Kernel#require` do not work. For example, given `foo.rb`: ```ruby # foo.rb % cat foo.rb module M def require(_path) puts "decorated" super end end Kernel.prepend(M) require 'tsort' ``` the decoration works normally: ``` % ruby -v foo.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +YJIT +PRISM [arm64-darwin25] decorated ``` and the same code does not work with the feature enabled: ``` % RUBY_BOX=1 ruby -v foo.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +YJIT +PRISM [arm64-darwin25] ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See https://docs.ruby-lang.org/en/4.0/Ruby/Box.html for known issues, etc. ``` With this, Zeitwerk cannot work because it totally depends on `Kernel#require` decoration (done [here](https://github.com/fxn/zeitwerk/blob/main/lib/zeitwerk/core_ext/kerne…) Bootsnap also depends on the ability of decorating `Kernel#require` (done [here](https://github.com/rails/bootsnap/blob/main/lib/bootsnap/load_path_ca…) On one hand, these gems are walking a fine line in the border of the public interface of Ruby. On the other hand, it is a goal of boxes to be transparent to the code being loaded under them. @tagomoris what should be the way to go in your opinion? /cc @byroot -- https://bugs.ruby-lang.org/

2 4

[ruby-core:121988] [Ruby Bug#21324] Namespace loads RubyGems in root Namespace but it should not
by Eregon (Benoit Daloze) 15 Feb '26

15 Feb '26

Issue #21324 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21324: Namespace loads RubyGems in root Namespace but it should not https://bugs.ruby-lang.org/issues/21324 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- RubyGems has tons of mutable state, isn't core library and isn't "builtin classes" either, so it should not be in root Namespace, as it is currently: ``` $ RUBY_NAMESPACE=1 ruby -ve 'ns = Namespace.new; p ns::Gem.equal?(Gem)' ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. true ``` A concrete example of what breaks most likely due to this: ``` $ gem i delegate:0.3.1 $ RUBY_NAMESPACE=1 ruby -ve 'require "delegate"; p Delegator::VERSION; ns = Namespace.new; File.write "ns.rb", "gem %{delegate}, %{0.3.1}; require :delegate.to_s; p Delegator::VERSION"; ns.require "./ns"' ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. "0.4.0" /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/specification.rb:2232:in 'Gem::Specification#check_version_conflict': can't activate delegate-0.3.1, already activated delegate-0.4.0 (Gem::LoadError) from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/specification.rb:1383:in 'Gem::Specification#activate' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'block in Kernel#gem' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'Thread::Mutex#synchronize' from /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_gem.rb:62:in 'Kernel#gem' from /home/eregon/ns.rb:1:in '<top (required)>' from -e:1:in 'Namespace#require' from -e:1:in '<main>' ``` i.e. `ns` sees delegate-0.4.0 was loaded in main namespace but it shouldn't. Previously mentioned in https://bugs.ruby-lang.org/issues/21311#note-36 -- https://bugs.ruby-lang.org/

5 8

[ruby-core:124198] [Ruby Feature#21781] Add `fetch_values` method on `ENV`
by Earlopain (Earlopain _) 14 Feb '26

14 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 3

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

14 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 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) 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