December 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:123875] [Ruby Feature#21701] Enumerator.produce accepts an optional `size` keyword argument
by knu (Akinori MUSHA) 03 Dec '25

03 Dec '25

Issue #21701 has been reported by knu (Akinori MUSHA). ---------------------------------------- Feature #21701: Enumerator.produce accepts an optional `size` keyword argument https://bugs.ruby-lang.org/issues/21701 * Author: knu (Akinori MUSHA) * Status: Open * Assignee: knu (Akinori MUSHA) * Target version: 4.0 ---------------------------------------- Enumerator::Producer#size currently always returns `Float::INFINITY`, and it is not specifiable. However, a produce sequence is known to be at least finite in many cases, and you can even tell or compute the exact size in some cases. ```ruby # Infinite enumerator enum = Enumerator.produce(1, size: Float::INFINITY, &:succ) enum.size # => Float::INFINITY # Finite enumerator with known/computable size abs_dir = File.expand_path("./baz") # => "/foo/bar/baz" traverser = Enumerator.produce(abs_dir, size: -> { abs_dir.count("/") + 1 }) { raise StopIteration if it == "/" File.dirname(it) } traverser.size # => 4 ``` As a background, Enumerator#to_set was changed to refuse to work against an infinite enumerator in https://bugs.ruby-lang.org/issues/21513. That made #to_set always fail against produce sequences. This enhancement will fix the problem (kind of) safely, and we will also be able to add the same size check to #to_a, which is currently missing and inconsistent with #to_set. Here's the implementation: https://github.com/ruby/ruby/pull/15277 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123971] [Ruby Bug#21756] Ripper fails to parse pathological heredoc
by Earlopain (Earlopain _) 03 Dec '25

03 Dec '25

Issue #21756 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21756: Ripper fails to parse pathological heredoc https://bugs.ruby-lang.org/issues/21756 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-28T10:49:46Z master dcb9e17f46) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```rb # test.rb pp <<-A, %w[j\ i A j] ``` ```sh $ RBENV_VERSION=ruby-dev ruby -rripper -ve "Ripper.lex(File.read('test.rb'), raise_errors: true)" ruby 4.0.0dev (2025-11-28T10:49:46Z master dcb9e17f46) +PRISM [x86_64-linux] /home/user/.rbenv/versions/ruby-dev/lib/ruby/4.0.0+0/ripper/lexer.rb:180:in 'Ripper::Lexer#parse': syntax error, unexpected literal content, expecting ' ' (SyntaxError) from /home/user/.rbenv/versions/ruby-dev/lib/ruby/4.0.0+0/ripper/lexer.rb:155:in 'Ripper::Lexer#lex' from /home/user/.rbenv/versions/ruby-dev/lib/ruby/4.0.0+0/ripper/lexer.rb:52:in 'Ripper.lex' from -e:1:in '<main>' ``` Both prism and parse.y are able to interpret this code: ```rb $ RBENV_VERSION=ruby-dev ruby test.rb "i\n" ["j\n", "j"] $ RBENV_VERSION=ruby-dev ruby --parser=parse.y test.rb "i\n" ["j\n" + "j"] ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123980] [Ruby Bug#21757] Splatted args array is mutated when passing unexpected kwargs
by apotonick (Nick Sutterer) 02 Dec '25

02 Dec '25

Issue #21757 has been reported by apotonick (Nick Sutterer). ---------------------------------------- Bug #21757: Splatted args array is mutated when passing unexpected kwargs https://bugs.ruby-lang.org/issues/21757 * Author: apotonick (Nick Sutterer) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The bug is very simple to provoke. ``` ruby proc = ->(*) { } # we do NOT expect any keyword arguments. args = [1, 2] proc.(*args, bug: true) pp args #=> [1, 2, {bug: true}] ``` The `args` array now has a third element which is exactly what got passed as keyword arguments. This is only in Ruby 3.4, 3.3 and below discard the "unexpected" keyword arguments as expected. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123504] [Ruby Bug#21645] Can't `require "resolve"` on Windows under Bundler without warnings
by Earlopain (Earlopain _) 02 Dec '25

02 Dec '25

Issue #21645 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21645: Can't `require "resolve"` on Windows under Bundler without warnings https://bugs.ruby-lang.org/issues/21645 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-19 master 957c832db1) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `prism` had disabled some workflows for ruby-head on windows because of the extraction from fiddle to being a bundled gem. I attempted to renable them now, but it is still an issue: https://github.com/ruby/prism/pull/3687 During `bundle install`, the `mini_portile2` gem (to build `nokogiri`) ends up requiring `net/http`, which in turn requires `resolv`. On windows, `resolv` requires `win32/resolv` here: https://github.com/ruby/ruby/blob/6eb75f6c36288cdd7522f27ad18608d13031f2b8/…. `win32-registry` depends on `fiddle`, and so under bundler it fails with the following: ``` D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/rubygems/specification.rb:1419:in 'block in Gem::Specification#activate_dependencies': Could not find 'fiddle' (~> 1.0) among 61 total gem(s) (Gem::MissingSpecError) Checked in 'GEM_PATH=D:/a/prism/prism/vendor/bundle/ruby/3.5.0+4' at: D:/rubyinstaller-head-x64/lib/ruby/gems/3.5.0+4/specifications/win32-registry-0.1.0.gemspec, execute `gem env` for more information from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/rubygems/specification.rb:1405:in 'Array#each' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/rubygems/specification.rb:1405:in 'Gem::Specification#activate_dependencies' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/rubygems/specification.rb:1387:in 'Gem::Specification#activate' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/rubygems/core_ext/kernel_gem.rb:62:in 'block in Kernel#gem' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/rubygems/core_ext/kernel_gem.rb:62:in 'Thread::Mutex#synchronize' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/rubygems/core_ext/kernel_gem.rb:62:in 'Kernel#gem' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/resolv.rb:1026:in 'Kernel#require' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/resolv.rb:1026:in 'Resolv::DNS::Config.default_config_hash' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/resolv.rb:95:in 'Resolv#initialize' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/resolv.rb:3469:in '<class:Resolv>' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/resolv.rb:35:in '<top (required)>' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/net/http.rb:25:in 'Kernel#require' from D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/net/http.rb:25:in '<top (required)>' from D:/a/prism/prism/vendor/bundle/ruby/3.5.0+4/gems/mini_portile2-2.8.9/lib/mini_portile2/mini_portile.rb:2:in 'Kernel#require' ``` I have tried to make a small reproduction by simply running `bundle exec ruby -rresolv` but there I just get a warning: ``` D:/rubyinstaller-head-x64/lib/ruby/3.5.0+4/win32/registry.rb:2: warning: fiddle/import is found in fiddle, which is not part of the default gems since Ruby 3.5.0. You can add fiddle to your Gemfile or gemspec to fix this error. ``` I am not sure why that is. I feel like it should at the very least raise. But I don't have a windows machine to investigate this. Here is a github action run that shows this: https://github.com/Earlopain/test/actions/runs/18653590178/job/53177107372 There is also a github issue: https://github.com/ruby/win32-registry/issues/11 -- https://bugs.ruby-lang.org/

4 11

[ruby-core:123484] [Ruby Bug#21640] Core Pathname is missing 3 methods / is partially-defined
by Eregon (Benoit Daloze) 01 Dec '25

01 Dec '25

Issue #21640 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21640: Core Pathname is missing 3 methods / is partially-defined https://bugs.ruby-lang.org/issues/21640 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ ruby -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > core_pathname_methods.txt $ ruby -rpathname -e 'puts Pathname.instance_methods(false).sort; puts Pathname.singleton_methods.sort' > require_pathname_methods.txt $ diff core_pathname_methods.txt require_pathname_methods.txt 36a37 > find 72a74 > rmtree 98a101 > mktmpdir ``` So `#find`, `#rmtree` and `.mktmpdir` are missing from core Pathname. And indeed, they give NoMethodError, e.g. ``` $ ruby -ve 'Pathname.new("doesnotexist").rmtree' ruby 3.5.0dev (2025-10-09T08:06:20Z master a29c90c3b0) +PRISM [x86_64-linux] -e:1:in '<main>': undefined method 'rmtree' for an instance of Pathname (NoMethodError) ``` I think this is confusing and unexpected for most users. Either Pathname should be fully defined or not at all, having a partially-defined Pathname seems particularly confusing (a bit like an autoload that failed in the middle or so). AFAIK the only core class which used to have this was Fiber with `alive?` and `transfer`, that certainly caused its share of confusion, and Fiber has since been fixed, now even without `require "fiber"` Fiber has all methods. Furthermore these 3 methods are not documented as needing `require 'pathname'` in their documentation: https://github.com/ruby/ruby/blob/master/lib/pathname.rb The reason these 3 methods are not in core pathname seems to be (from [this comment](https://github.com/ruby/pathname/issues/64#issuecomment-3388907046)) > That's consensus with akr and me. We should avoid loading other libraries by simply calling methods from the embedded core classes. I understand that concern and I share it, but I think the situation of having a partially-defined Pathname in core is quite problematic. I think there are 2 solutions: * Define all Pathname methods in core. The `require` are done lazily inside the methods so AFAIK there is no technical issue blocking that, but it's not ideal design-wise that a core class can load default gems (i.e. give up that concern for this particular case). * Do not define Pathname in core and let it be a default gem as it was in Ruby 3.4. I discuss the second in more details, because I found more problems than I would have imagined with core Pathname: ## Should Pathname be in core? #17473 proposed to make Pathname core. That sounded great to me at first thought, but as I realize the practical problems with it I'm thinking it's actually better to keep Pathname non-core and as a default gems. Here are concerns with having Pathname in core: 1. Pathname inherently depends on other default gems/stdlib like `find`, `fileutils` and `tmpdir`. This is important to make Pathname useful. The docs even phrase it like this: `ri Pathname` > ... > All functionality from File, FileTest, and some from Dir and > FileUtils is included, in an unsurprising way. It is essentially a > facade for all of these, and more. 2. core Pathname is missing 3 methods compared to gem Pathname (shown above) 3. the pathname gem is likely to gain extra features, methods and bug fixes. For example I see [4 PRs](https://github.com/ruby/pathname/pulls) adding new methods. It means core Pathname will always be outdated and potentially missing some new methods. 4. One can still use the pathname gem even if it's in core, but surprisingly just `require 'pathname'` is not enough: ``` $ gem install pathname Building native extensions. This could take a while... Successfully installed pathname-0.4.0 1 gem installed $ ruby -e 'require "pathname"; puts $".grep(/pathname/)' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb ^ wrong that's the stdlib pathname $ ruby -e 'gem "pathname"; require "pathname"; puts $".grep(/pathname/)' # some warnings, reported in https://github.com/ruby/pathname/issues/66 pathname.so /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/pathname-0.4.0/lib/pathname.rb ^ correct ``` This is another source of confusion caused by core pathname. It even happens with Bundler! ``` $ cat Gemfile source "https://rubygems.org" gem "pathname" $ bundle install $ ruby -e 'require "bundler/setup"; require "pathname"; puts $".grep(/pathname/); puts; puts $:' pathname.so /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/pathname.rb /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/gems/pathname-0.4.0/lib /home/eregon/tmp/bundler-pathname/vendor/bundle/ruby/3.5.0+4/extensions/x86_64-linux/3.5.0+4-static/pathname-0.4.0 /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+4/gems/bundler-2.8.0.dev/lib /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/site_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/site_ruby /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby/3.5.0+4/x86_64-linux /home/eregon/prefix/ruby-master/lib/ruby/vendor_ruby /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4 /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+4/x86_64-linux $ bundle exec ruby -e 'require "pathname"; puts $".grep(/pathname/); puts; puts $:' same as above ``` I'm not sure why, but that seems a serious bug that the `pathname` gem apparently can't be used at all with Bundler. 4. due to this difference in terms of methods for core & gem pathname it seems complicated to keep core Pathname and gem Pathname in sync, since e.g. everything is naturally in one `.rb` file in the gem, but in two `.rb` files in core 5. the pathname gem has to `remove_const :Pathname` to avoid conflicts and warnings in https://github.com/ruby/pathname/blob/4689b0b78d081ae855f325e086d95803fa5bd…. This is bad for Ruby JITs, especially if core Pathname methods might have been used, as it will invalidate JITs compilations, invalidate some inline caches (also bad for the interpreter), caused the JIT to do more compilations which means slower warmup, makes it much harder to persist JITed code across process executions, etc. Based on all of these I think it would actually be better to not have Pathname in core, and let it be a default gem. Having to `require "pathname"` as one always needed to do so far seems far better than a partially-defined core Pathname with rough edge cases (those concerns). -- https://bugs.ruby-lang.org/

6 21

[ruby-core:117618] [Ruby master Feature#20437] Could be the licensing conditions be made less ambiguous?
by vo.x (Vit Ondruch) 01 Dec '25

01 Dec '25

Issue #20437 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Feature #20437: Could be the licensing conditions be made less ambiguous? https://bugs.ruby-lang.org/issues/20437 * Author: vo.x (Vit Ondruch) * Status: Open ---------------------------------------- # Current state The current [COPYING](https://github.com/ruby/ruby/blob/6cfd929034f1fe3d93160365505a8b88… file says the following: ~~~ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the 2-clause BSDL (see the file BSDL), or the conditions below: 1. You may make and give away verbatim copies of the source form of the ... snip ... ~~~ And this is quite ambiguous. Let me show a few examples: # Ambiguous examples ## lib/net/protocol.rb https://github.com/ruby/ruby/blob/6cfd929034f1fe3d93160365505a8b88bef56159/… ~~~ # This program is free software. You can re-distribute and/or # modify this program under the same terms as Ruby itself, # Ruby Distribute License or GNU General Public License. ~~~ So what is the license? Is it 2-clause BSDL + Ruby + GPL? Or is is just Ruby + GPL but not 2-clause BSDL? ## Racc https://github.com/ruby/racc/blob/d52fb64d166046bfde81e6e9c424fcd884ebcabf/… ~~~ Racc is distributed under the same terms of ruby. (see the file COPYING). ~~~ where the [COPYING](https://github.com/ruby/racc/blob/d52fb64d166046bfde81e6e9c424fcd8… contains just 2-clause BSDL. Not even mentioning that Ruby used to be GPLv2 licensed: https://github.com/ruby/racc/commit/cc7fe952a6b1fc2ef43477674fa13f2d9d99e818 ## Rubygems https://github.com/rubygems/rubygems/blob/master/LICENSE.txt The license is obviously modeled after Ruby COPYING file, but if it could say "licensed under MIT or Ruby", it would be much better. ## Gettext https://github.com/ruby-gettext/gettext/blob/8d84132efd888e68fffbce41331645… The license note is so old that it is not obvious what that means and what was the intention. Did the Ruby relicensing from "GPLv2 or Ruby" to "GPLv2 or BSD" influenced this project? ## SPDX https://spdx.org/licenses/Ruby.html It quotes just the "conditions below" as a Ruby license, while referring to [Ruby license file](https://www.ruby-lang.org/en/about/license.txt) mentioning also 2-clause BSDL # Proposal To me it seems that the whole world recognizes "Ruby" license, except Ruby. Therefore I think it would be nice if Ruby project recognized the "Ruby" license. There are two possibilities I can think of: ## Refer the license by name ~~~diff $ git diff diff --git a/COPYING b/COPYING index 48e5a96de7..a2d179a8a9 100644 --- a/COPYING +++ b/COPYING @@ -1,6 +1,6 @@ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the -2-clause BSDL (see the file BSDL), or the conditions below: +2-clause BSDL (see the file BSDL), or the conditions of the Ruby license below: 1. You may make and give away verbatim copies of the source form of the software without restriction, provided that you duplicate all of the ~~~ ## Extract the "conditions below" into "Ruby" license file The "conditions below" text could be extracted into separate file (e.g. "RUBY_LICENSE") and the "COPYING" file rephrased to say: ~~~ Ruby is copyrighted free software by Yukihiro Matsumoto <matz(a)netlab.jp>. You can redistribute it and/or modify it under either the terms of the 2-clause BSDL (see the file BSDL), or Ruby license (see the file RUBY_LICENSE) ~~~ -- https://bugs.ruby-lang.org/

3 7