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

[ruby-core:124824] [Ruby Bug#21879] SSLBypass
by sh2ll (Chmouel Taieb) 15 Feb '26

15 Feb '26

Issue #21879 has been reported by sh2ll (Chmouel Taieb). ---------------------------------------- Bug #21879: SSLBypass https://bugs.ruby-lang.org/issues/21879 * Author: sh2ll (Chmouel Taieb) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- There is not enough space for photos upload ---Files-------------------------------- Critical SSL Verification Bypass Report.pdf (87.4 KB) ScriptsPOC.pdf (49.5 KB) -- https://bugs.ruby-lang.org/

3 2

[ruby-core:115196] [Ruby master Feature#19979] Allow methods to declare that they don't accept a block via `&nil`
by ufuk (Ufuk Kayserilioglu) 15 Feb '26

15 Feb '26

Issue #19979 has been reported by ufuk (Ufuk Kayserilioglu). ---------------------------------------- Feature #19979: Allow methods to declare that they don't accept a block via `&nil` https://bugs.ruby-lang.org/issues/19979 * Author: ufuk (Ufuk Kayserilioglu) * Status: Open * Priority: Normal ---------------------------------------- ## Abstract This feature proposes new syntax to allow methods to explicitly declare that they don't accept blocks, and makes passing of a block to such methods an error. ## Background In #15554, it was proposed to automatically detect methods that do not use the block passed to them, and to error if a block was passed to such methods. As far as I can tell, it was later on closed since #10499 solved a large part of the problem. That proposal has, as part of the dev meeting discussion, a proposal from @matz to allow methods to use `&nil` to explicitly declare that they don't accept a block. At the time, the proposal was trying to solve a bigger problem, so this sub-proposal was never considered seriously. However, notes in the proposal say: > It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations) This proposal extracts that sub-proposal to make this a new language feature. ## Proposal In Ruby, it is always valid for the caller to pass a block to a method call, even if the callee is not expecting a block to be passed. This leads to subtle user errors, where the author of some code assumes a method call uses a block, but the block passed to the method call is silently ignored. The proposal is to introduce `&nil` at method declaration sites to mean "This method does not accept a block". This is symmetric to the ability to pass `&nil` at call sites to mean "I am not passing a block to this method call", which is sometimes useful when making `super` calls (since blocks are always implicitly passed). Explicitly, the proposal is to make the following behaviour be a part of Ruby: ```ruby def find(item = nil, &nil) # some implementation that doesn't call `yield` or `block_given?` end find { |i| i == 42 } # => ArgumentError: passing block to the method `find' that does not accept a block. ``` ## Implementation I assume the implementation would be a grammar change to make `&nil` valid at method declaration sites, as well as raising an `ArgumentError` for methods that are called with a block but are declared with `&nil`. ## Evaluation Since I don't have an implementation, I can't make a proper evaluation of the feature proposal. However, I would expect the language changes to be minimal with no runtime costs for methods that don't use the `&nil` syntax. ## Discussion This proposal has much smaller scope than #15554 so that the Ruby language can start giving library authors the ability to explicitly mark their methods as not accepting a block. This is fully backward compatible, since it is an opt-in behaviour and not an opt-out one. Future directions after this feature proposal could be a way to signal to the VM that any method in a file that doesn't explicitly use `yield`/`block_given?` or explicitly declared a block parameter should be treated as not accepting a block. This can be done via some kind of pragma similar to `frozen_string_literal`, or through other means. However, such future directions are beyond the scope of this proposal. ## Summary Adding the ability for methods to declare that they don't accept a block will make writing code against such methods safer and more resilient, and will prevent silently ignored behaviour that is often hard to catch or troubleshoot. -- https://bugs.ruby-lang.org/

10 25

[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