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

[ruby-core:121791] [Ruby Bug#21298] `ObjectSpace.allocation_class_path` returns inconsistent results depending on `TracePoint` state
by mame (Yusuke Endoh) 05 Dec '25

05 Dec '25

Issue #21298 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21298: `ObjectSpace.allocation_class_path` returns inconsistent results depending on `TracePoint` state https://bugs.ruby-lang.org/issues/21298 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: tenderlovemaking (Aaron Patterson) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `ObjectSpace.allocation_class_path` is an API that returns the class of `self` in the context where an object was allocated. However, due to recent optimizations in `Class#new` (#21254), the return value now changes depending on whether `TracePoint` is enabled. ```ruby require "objspace" class Foo def test obj = Object.new ObjectSpace.allocation_class_path(obj) end end ObjectSpace.trace_object_allocations_start p Foo.new.test #=> 3.4.2: "Class", master: "Foo" ``` Previously, this returned `"Class"` (from the `Class#new` call frame), but in the master branch, the result is now `"Foo"` because that frame is gone. I am ok for the incompatibility itself because I find the new behavior more intuitive and useful. However, there's an inconsistency: the optimization is disabled when `TracePoint` is enabled, causing the result to revert to the old behavior. ```ruby p Foo.new.test #=> master: "Foo" TracePoint.new {}.enable do p Foo.new.test #=> master: "Class", expected: "Foo" end ``` This makes behavior dependent on whether `TracePoint` is enabled, which can lead to confusion. @ko1 @tenderlovemaking Can we make `ObjectSpace.allocation_class_path` consistently return the class from the `.new` call context, regardless of the `TracePoint` state? --- I am facing a failure of the following test when code coverage (which uses `TracePoint`) is enabled: https://github.com/ruby/ruby/blob/e8ad728209ee22136e61054fea74096b49088b8a/… As a short-term workaround, I'm considering commenting out this test. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:112326] [Ruby master Feature#19430] Contribution wanted: DNS lookup by c-ares library
by mame (Yusuke Endoh) 05 Dec '25

05 Dec '25

Issue #19430 has been reported by mame (Yusuke Endoh). ---------------------------------------- Feature #19430: Contribution wanted: DNS lookup by c-ares library https://bugs.ruby-lang.org/issues/19430 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- ## Problem At the present time, Ruby uses `getaddrinfo(3)` to resolve names. Because this function is synchronous, we cannot interrupt the thread performing name resolution until the DNS server returns a response. We can see this behavior by setting blackhole.webpagetest.org (72.66.115.13) as a DNS server, which swallows all packets, and resolving any name: ``` # cat /etc/resolv.conf nameserver 72.66.115.13 # ./local/bin/ruby -rsocket -e 'Addrinfo.getaddrinfo("www.ruby-lang.org", 80)' ^C^C^C^C ``` As we see, Ctrl+C does not stop ruby. The current workaround that users can take is to do name resolution in a Ruby thread. ```ruby Thread.new { Addrinfo.getaddrinfo("www.ruby-lang.org", 80) }.value ``` The thread that calls this code is interruptible. (Note that the newly created thread itself will be stuck until the DNS lookup exceeds the time out.) ## Proposal We can solve this problem by using c-ares, which is an asynchronous name resolver, as a backend of `Addrinfo.getaddrinfo`, etc. (@sorah told me about this library, thanks!) https://c-ares.org/ I have created a PoC patch. https://github.com/mame/ruby/commit/547806146993bbc25984011d423dcc0f913b211c By applying this patch, we can interrupt `Addrinfo.getaddrinfo` by Ctrl+C. ``` # cat /etc/resolv.conf nameserver 72.66.115.13 # ./local/bin/ruby -rsocket -e 'Addrinfo.getaddrinfo("www.ruby-lang.org", 80)' ^C-e:1:in `getaddrinfo': Interrupt from -e:1:in `<main>' ``` ## Discussion ### About c-ares According to the site of c-ares, some major tools including libcurl, Wireshark, and Apache Arrow are already using c-ares. In the language interpreter, node.js seems to be using c-ares. I am honestly not sure about the compatibility of c-ares with `getaddrinfo(3)`. I guess there is no major incompatibility because I have not experienced any name resolution problem of curl. @akr (who is the author and maintainer of Ruby's socket library) suggested to check if OS-specific name resolution, e.g., WINS on Windows, NIS on Solaris, etc., is supported. He also said that it may be acceptable even if they are not supported. Whether to bundle c-ares source code with ruby would require further discussion. If this proposal is accepted, then c-ares will become a de facto essential dependency for practical use, like gmp, in my opinion. Incidentally, node.js bundles c-ares: https://github.com/nodejs/node/tree/main/deps/cares ### Alternative approaches Recent glibc provides `getaddrinfo_a(3)` which performs asynchronous name resolution. However, this function has a fatal problem of being incompatible with `fork(2)`, which is heavily used in the Ruby ecosystem. In fact, the attempt to use `getaddrinfo_a(3)` (#17134) has been revert because it fails rails tests. (#17220) Another alternative is to have a worker pthread inside Ruby that calls getaddrinfo(3). Instead of calling getaddrinfo(3) directly, `Addrinfo.getaddrinfo` would ask the worker to resolve a name and wait for a response. This method should be able to implement cancellation. (Simply put, this means reimplementation of getaddrinfo_a(3) on our own, taking into account of `fork(2).) This has the advantages: not adding dependencies on external libraries and not having compatibility issues with `getaddrinfo(3)`. However, it is considerably more difficult to implement and maintain. An internal pthread may have a non-trivial impact on the execution efficiency and memory usage. Also, we may need to implement a mechanism to dynamically change the number of workers depending on the load. It would be ideal if we could try and evaluate both approaches. But my current impression is that using c-ares is the quickest and best compromise. ## Contribution wanted I have made it up to the PoC, but don't have much time to complete this. @naruse suggested me to create a ticket asking for contributions. Is anyone interested in this? * This patch changes `rsock_getaddrinfo` to accept a timeout argument. There are several places where Qnil is passed as a timeout (where I add `// TODO` in the PoC). We need to consider what timeout we should pass. * This cares only `getaddrinfo`, but we also need to care `getnameinfo` (and something else if any). There may be some issues I'm not aware of. * I have not yet tested this PoC seriously. It would be great if we could evaluate it with some real apps. Also, it would be great to hear from someone who knows more about c-ares. -- https://bugs.ruby-lang.org/

6 16

[ruby-core:123983] [Ruby Bug#21758] Prism fails to parse heredoc within %Q literal split by another heredoc
by tompng (tomoya ishida) 04 Dec '25

04 Dec '25

Issue #21758 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21758: Prism fails to parse heredoc within %Q literal split by another heredoc https://bugs.ruby-lang.org/issues/21758 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-02T16:20:43Z master c06c2203ed) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Prism fails to parse this code ~~~ruby <<A; %Q A #{<<B} B ~~~ Parse error: ~~~ a.rb:4: syntax error found (SyntaxError) 2 | A 3 | #{<<B} > 4 | B | ^ unexpected constant, expecting end-of-input ~~~ `B` at line 4 appears twice in lex result: ~~~ruby Prism.lex('<<A; %Q A #{<<B} B ').value #=> [[HEREDOC_START(1,0)-(1,3)("<<A"), 1], [HEREDOC_END(2,0)-(3,0)("A\n"), 2], [SEMICOLON(1,3)-(1,4)(";"), 1], [STRING_BEGIN(1,5)-(2,0)("%Q\n"), 1], [EMBEXPR_BEGIN(3,0)-(3,2)("\#{"), 1], [HEREDOC_START(3,2)-(3,5)("<<B"), 1], [HEREDOC_END(4,0)-(5,0)("B\n"), 2], # B\n here [EMBEXPR_END(3,5)-(3,6)("}"), 2], [STRING_END(3,6)-(4,0)("\n"), 2], [CONSTANT(4,0)-(4,1)("B"), 2], # Same B again here [NEWLINE(4,1)-(5,0)("\n"), 1], [EOF(4,1)-(5,0)("\n"), 1]] ~~~ -- https://bugs.ruby-lang.org/

3 3

[ruby-core:123961] [Ruby Feature#21722] Expose rb_gc_mark_weak API for use in extensions
by ivoanjo (Ivo Anjo) 04 Dec '25

04 Dec '25

Issue #21722 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Feature #21722: Expose rb_gc_mark_weak API for use in extensions https://bugs.ruby-lang.org/issues/21722 * Author: ivoanjo (Ivo Anjo) * Status: Open ---------------------------------------- In https://bugs.ruby-lang.org/issues/21710 it came up that 1. On top of [deprecating _id2ref](https://bugs.ruby-lang.org/issues/15408) on Ruby 4.0, [it's a bad idea to be using object_id from the NEWOBJ tracepoint](https://bugs.ruby-lang.org/issues/21710#note-8) 2. `rb_gc_mark_weak` which would be the alternative for an extension that needs weak reference-like behavior [is not available for extensions](https://bugs.ruby-lang.org/issues/21710#note-9) So I've opened this ticket to request exposing `rb_gc_mark_weak` so it can be used by extensions? --- The [Datadog Ruby profiler](https://github.com/datadog/dd-trace-rb) is currently using object_id and id2ref to implement its "heap profiling" -- that is, we have a NEWOBJ tracepoint, and from time to time (e.g. not for every object), we select an object, and track its lifetime by keeping its id and checking from time to time if it's still alive. We're using this approach instead of: * The FREEOBJ event => Reduced overhead, as we don't need to be called for every object (+ not needing to deal with corner cases of when FREEOBJ may not be called for an object) * WeakMap => Weakmap APIs are Ruby-level and need the GVL, and thus make it hard to use from low-level tracepoints and to avoid overhead by doing profiler work with the GVL released. For our purposes, it would be OK if this API is not "official" -- e.g. if it's one of those that gets exposed as a public symbol but not documented and no promises made for future Ruby releases. -- https://bugs.ruby-lang.org/

4 5

[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) 03 Dec '25

03 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: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