February 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:124821] [Ruby Feature#17513] Methods of shareable objects and UnboundMethods should be shareable
by trinistr (Alexander Bulancov) 13 Feb '26

13 Feb '26

Issue #17513 has been updated by trinistr (Alexander Bulancov). A `def`-ed method of a shareable object may depend on unshareable state. Even worse, shareability of state may dynamically change: ```ruby module Checker CHECK = [] def check? CHECK.include?(self) end end class A; include Checker; end obj = A.new.freeze Ractor.shareable?(obj) # => true Ractor.new(obj) { |o| p o.check? } # Ractor::IsolationError Checker::CHECK.freeze Ractor.new(A.new.freeze) { |o| p o.check? } # false Checker::CHECK = [] # And here we go again ``` ---------------------------------------- Feature #17513: Methods of shareable objects and UnboundMethods should be shareable https://bugs.ruby-lang.org/issues/17513#change-116442 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Assignee: ko1 (Koichi Sasada) ---------------------------------------- ```ruby class Foo def foo end end f = Foo.new.freeze Ractor.shareable?(f) # => true Ractor.make_shareable(f.method(:foo).to_proc) # => Proc, ok Ractor.make_shareable(f.method(:foo)) # => Ractor::Error, expected Method Ractor.make_shareable(Foo.instance_method(:foo)) # => Ractor::Error, expected UnboundMethod ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124820] [Ruby Feature#6478] BasicObject#__class__
by trinistr (Alexander Bulancov) 13 Feb '26

13 Feb '26

Issue #6478 has been updated by trinistr (Alexander Bulancov). jneen (Jeanine Adkisson) wrote in #note-16: > I wonder if exposing a static `Object.class_of(thing)` would be appropriate? There's also the singleton_class to consider as well. This is an interesting idea. It would solve the problems around this, in a simpler way than an `UnboundMethod`. But it defintely feels off for Ruby, though we have some methods like that (`Regexp.linear_time?` comes to mind). Eregon (Benoit Daloze) wrote in #note-19: > I think at least it's clear it's not good to go towards having every `Kernel` method as a `__x__` variant on BasicObject. > Also even `__send__` and `__id__` can be redefined, so the `KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj)` approach is in fact safer. > > So my take on this is `KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj)` is good enough, > and also most BasicObject subclasses should implement Kernel-like methods. > > Concrete examples from real code where this is not good enough would most likely be helpful to move this forward if people want that. I agree, porting all methods from Kernel is unreasonable. It's just that having access to object's class is fundamental and would provide replacements for many generic methods (especially `methods` and co). In my experience, `__class__` would be much more useful than `__id__`, for example. IMHO, redefining basic methods is not a compelling argument, `Kernel#class` could be redefined too. On the other hand, `#class` being redefined [happens](https://github.com/search?q=%2Fdef+class%5Cb%2F+language%3Aruby&re… more often than for `#__class__`. > `KERNEL_CLASS = Kernel.instance_method(:class)` This looks even less Ruby-like to me than a silly method name :p Also, due to constant resolution, placing such constants requires extra consideration or littering the code with them. > Concrete examples from real code where this is not good enough would most likely be helpful to move this forward if people want that. ```ruby Ractor.shareable?(Kernel.instance_method(:class)) # => false ``` So Ractor-compatible code can not use such a constant (relevant #17513 is still open). And just basic stuff like this would be much easier to write: ```ruby def my_chunkers(collection) raise ArgumentError, "#{collection.__class__} is not enumerable" unless Enumerable === collection collection.chunk(&:itself) end ``` byroot (Jean Boussier) wrote in #note-18: > > Why not add BasicObject#class? > > I suspect that would break various proxy classes in gems. Might not be a huge deal. That's that I thought, too, there probably is code relying on `class` being proxied, otherwise I would push for that name. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116441 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124811] [Ruby Feature#21878] More file types: DOOR, PORT, WHITEOUT
by nobu (Nobuyoshi Nakada) 13 Feb '26

13 Feb '26

Issue #21878 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #21878: More file types: DOOR, PORT, WHITEOUT https://bugs.ruby-lang.org/issues/21878 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I found recent Python supports these file types: [S_ISDOOR](https://docs.python.org/3.14/library/stat.html#stat.S_ISDOOR) [S_ISPORT](https://docs.python.org/3.14/library/stat.html#stat.S_ISPORT) [S_ISWHT](https://docs.python.org/3.14/library/stat.html#stat.S_ISWHT) even they [return `False` always](https://github.com/python/cpython/blob/3.14/Lib/stat.py#L78-L88). What about supporting them in Ruby? -- https://bugs.ruby-lang.org/

4 3

[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:124805] [Ruby Feature#14737] Split default gems into separate directory structure
by hsbt (Hiroshi SHIBATA) 13 Feb '26

13 Feb '26

Issue #14737 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Rejected I have no plan to apply this proposal. I understand that the current situation is not optimal, but there is no advantage to change it considering that this structure has been in use for eight years with no critical issues. ---------------------------------------- Feature #14737: Split default gems into separate directory structure https://bugs.ruby-lang.org/issues/14737#change-116422 * Author: vo.x (Vit Ondruch) * Status: Rejected * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- On Fedora, we are using operating_system.rb [1], [2] to setup various RubyGems paths. Unfortunately, if we change Gem.default_dir (which we want to point into user home directory on Fedora), then this also changes location for default gems (!!), which are later not discovered by RubyGems [3]. It was not been a big deal for use, since we used to unbundle the gems shipped in Ruby, but with the gemification of StdLib, unbundlig becomes unsustainable (it is more work, but mainly it is incompatible change). To fix this issue, I modified the operating_system.rb to behave similarly to what Arch does [4], i.e. we started to inject "--user-install" option [1]. Unfortunately, this revealed the RubyGems are not respecting their own interfaces and I had to fix at least one of them along the way to make it work [6]. Apparently, using the "--user-install" option itself has some drawbacks and what is worse, it is not respected by Bundler, which was recently pointed out [5]. When I was fixing RubyGems [6], I just realized how the default gems are hacked up and how much is the original RubyGems configurability broken by this. This leads me to the proposal: **Could we please install default gems into different directory then the other, user installed, gems?** Since RubyGems were always designed to support various gem directory structures, the directory structure for default gems would become just other directory directory structure and would not collide with overrides in operating_system.rb, letting the distributions to override what was always designed to be overridable. BTW I believe that one nice side effect of this change would be simplification of RubyGems code base. The default gems would live in "default_gems" directory, their .gemspec files could be in standard "default_gems/specifications" directory and we could forget about "default_gems/specifications/defaults", etc. BTW2 I could fill this against RubyGems, but the default gems are Ruby stuff IMO, so I think this is appropriate tracker. [1]: https://src.fedoraproject.org/rpms/ruby/blob/master/f/operating_system.rb [2]: https://src.fedoraproject.org/rpms/ruby/blob/f27/f/operating_system.rb [3]: https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.… [4]: https://wiki.archlinux.org/index.php/ruby [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1574594 [6]: https://github.com/rubygems/rubygems/pull/2116 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124803] [Ruby Feature#21822] Expose Return Value in the ensure Block
by artemb (Artem Borodkin) 12 Feb '26

12 Feb '26

Issue #21822 has been updated by artemb (Artem Borodkin). > ``` > begin > ret = begin > # .... > end > ensure > LOGGER.debug "return value: #{ret}" > end > ``` For me, ensure => ret looks cleaner, reduces cognitive overhead, and is simply easier on the eyes when reviewing real code. The structure is easier to parse visually, and the intent is clearer compared to the alternatives. Also, it doesn’t break any existing behavior — it’s purely additive, just a small but useful extension that makes the code more elegant and pleasant to read. ---------------------------------------- Feature #21822: Expose Return Value in the ensure Block https://bugs.ruby-lang.org/issues/21822#change-116419 * Author: artemb (Artem Borodkin) * Status: Open ---------------------------------------- I'd like to propose a simple feature that allows easy access to the return value inside an ensure block. ```ruby begin # ... ensure => ret # ret is nil if an exception is raised LOGGER.debug "return value: #{ret}" end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124684] [Ruby Feature#21863] Add RBASIC_FLAGS() and RBASIC_SET_FLAGS()
by Eregon (Benoit Daloze) 12 Feb '26

12 Feb '26

Issue #21863 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21863: Add RBASIC_FLAGS() and RBASIC_SET_FLAGS() https://bugs.ruby-lang.org/issues/21863 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- Currently there is `RBASIC_CLASS()` which is the same as `RBASIC(obj)->klass` on CRuby but also checks it's called on a valid object: https://github.com/ruby/ruby/blob/86dba8cfaeabb3b86df921da24b3243b9ce4ab2a/… I would like to add `RBASIC_FLAGS()` and `RBASIC_SET_FLAGS()`, which could be defined like this on CRuby: ```c #define RBASIC_FLAGS(obj) (RBASIC(obj)->flags) #define RBASIC_SET_FLAGS(obj, flags_to_set) (RBASIC(obj)->flags = flags_to_set) ``` This would let native extensions access those flags without relying on the specific fields, layout and existence of a `RBasic` `struct`. My main motivation here is that TruffleRuby, the alternative Ruby implementation with the most complete native extension support, cannot support having mutable fields in `RBasic`. The reason is because flags are mutable, it would be impossible to find out when the user writes to the flags if they write with just `RBASIC(obj)->flags = v`. And since the state related to flags is held internally on the Java object, writing to native memory would do nothing, which would be incompatible. With these macros we can know when the user writes to the flags and update the internal representation. In fact, TruffleRuby already implements these macros, since [this comment](https://github.com/truffleruby/truffleruby/issues/3118#issuecommen…. I would like to make it a standard C API to increase adoption and make it easier to discover. This would also be useful on CRuby to do additional checks when reading and writing flags: * We could add `RBIMPL_ASSERT_OR_ASSUME(!RB_SPECIAL_CONST_P(obj));` like `RBASIC_CLASS` does. * We could check that the frozen flag is not removed. * We could check that the frozen flag is consistent with the frozen flag on the object shape (if CRuby has a frozen flag in the shape). * We could check that the shape is not changed by native extensions this way (since the shape is stored in flags on 64-bit machines). * CRuby would be able to evolve the representation of RBasic more freely in the future. I'll note that there are already some macros/functions to manipulate flags such as `RB_FL_TEST()`, however they don't allow just reading or writing the flags: https://github.com/ruby/ruby/blob/86dba8cfaeabb3b86df921da24b3243b9ce4ab2a/… However it seems clear that C extensions do read and write the RBasic->flags field currently and these `RB_FL_*()` macros/functions are not enough, so `RBASIC_FLAGS()` and `RBASIC_SET_FLAGS()` would be obvious replacements. Here is a gem-codesearch for `/RBASIC$.+$->flags/`: https://gist.github.com/eregon/5866bd86e626ae723b5b16d935af8f94 An alternative would be to deprecate the RBasic->flags field entirely and eventually hide it, and don't provide a replacement for direct reading/writing flags, but that would break a bunch of native extensions, so it does not seem actionable. With this proposal we won't break anything and we'll actually get finer control over accesses to flags if e.g. we want to prevent some invariant-breaking changes. -- https://bugs.ruby-lang.org/

1 2