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

[ruby-core:120710] [Ruby master Feature#21042] Add and expose Thread#memory_allocations memory allocation counters
by stanhu (Stan Hu) 08 May '25

08 May '25

Issue #21042 has been reported by stanhu (Stan Hu). ---------------------------------------- Feature #21042: Add and expose Thread#memory_allocations memory allocation counters https://bugs.ruby-lang.org/issues/21042 * Author: stanhu (Stan Hu) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- For the last 5 years, we've been patching our Ruby interpreter with https://github.com/ruby/ruby/pull/3978 in order to track memory allocations over time. This has been running in production at GitLab for a long time. I'd like to request approval for this patch to land upstream since we're getting tired of maintaining this patch, and this data seems like it would be generally useful. If this can be done via a C extension, let me know, and I can look at that. Copying from that pull request: ### Design This is designed to measure a memory allocations in a multi-threaded environments (concurrent requests processing) with an accurate information about allocated memory within a given execution context. The idea here is to provide as cheap as possible counter without an overhead of calling callbacks, and provide this information on a per-thread basis. ### Implementation This adds `Thread.current.memory_allocations`, which provides information about: * total_allocated_objects * total_malloc_bytes * total_mallocs This is based on a expectation, that allocation for a given thread always happens with a `rb_current_thread()` properly indicating a thread performing allocation. This measures total number of allocations as counters. Now, since the removal of objects is async and happening at random moment, the same cannot be said for deallocations, thus only allocations are tracked. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:121565] [Ruby Feature#21254] Inlining Class#new
by tenderlovemaking (Aaron Patterson) 07 May '25

07 May '25

Issue #21254 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21254: Inlining Class#new https://bugs.ruby-lang.org/issues/21254 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- We would like to propose inlining YARV bytecode for speeding up object allocations, specifically inlining the `Class#new` method. In order to support inlining this method, we would like to introduce a new YARV instruction `opt_new`. This instruction will allocate an object if the default allocator is not overridden, otherwise it will jump to a “slow path” for calling a method. `Class#new` especially benefits from inlining for two reasons: 1. Calling `initialize` directly means we don't need to allocate a temporary hash for keyword arguments 2. We are able to use an inline cache when calling the `initialize` method The patch can be found [here](https://github.com/ruby/ruby/pull/13080), but please find implementation details below. ## Implementation Details This patch modifies the compiler to emit special instructions when it sees a callsite that uses “new”. Before this patch, calling `Object.new` would result in bytecode like this: ``` ruby --dump=insns -e'Object.new' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 opt_getconstant_path <ic:0 Object> ( 1)[Li] 0002 opt_send_without_block <calldata!mid:new, argc:0, ARGS_SIMPLE> 0004 leave ``` With this patch, the bytecode looks like this: ``` ./ruby --dump=insns -e'Object.new' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 opt_getconstant_path <ic:0 Object> ( 1)[Li] 0002 putnil 0003 swap 0004 opt_new <calldata!mid:new, argc:0, ARGS_SIMPLE>, 11 0007 opt_send_without_block <calldata!mid:initialize, argc:0, FCALL|ARGS_SIMPLE> 0009 jump 14 0011 opt_send_without_block <calldata!mid:new, argc:0, ARGS_SIMPLE> 0013 swap 0014 pop 0015 leave ``` The new `opt_new` instruction checks whether or not the `new` implementation is the default “allocator” implementation. If it is the default allocator, then the instruction will allocate the object and call initialize passing parameters to initialize but not to `new`. If the method is not the default allocator implementation, it will jump to the normal method dispatch instructions. Performance Improvements This patch improves performance of all allocations that use the normal “new” method for allocation. Here are two examples (all of these benchmarks compare Ruby 3.4.2 against Ruby master with inlining patch): A simple `Object.new` in a hot loop improves by about 24%: ``` hyperfine "ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end'" "./ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end'" Benchmark 1: ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end' Time (mean ± σ): 436.6 ms ± 3.3 ms [User: 432.3 ms, System: 3.8 ms] Range (min … max): 430.5 ms … 442.6 ms 10 runs Benchmark 2: ./ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end' Time (mean ± σ): 351.1 ms ± 3.6 ms [User: 347.4 ms, System: 3.3 ms] Range (min … max): 343.9 ms … 357.4 ms 10 runs Summary ./ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end' ran 1.24 ± 0.02 times faster than ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end' ``` Using a single keyword argument is improved by about 72%: ``` > hyperfine "ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end'" "./ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end'" Benchmark 1: ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end' Time (mean ± σ): 1.082 s ± 0.007 s [User: 1.074 s, System: 0.008 s] Range (min … max): 1.071 s … 1.091 s 10 runs Benchmark 2: ./ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end' Time (mean ± σ): 627.6 ms ± 4.8 ms [User: 622.6 ms, System: 4.5 ms] Range (min … max): 622.1 ms … 637.2 ms 10 runs Summary ./ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end' ran 1.72 ± 0.02 times faster than ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end' ``` The performance increase depends on the number and type of parameters passed to `initialize`. For example, an `initialize` method that takes 3 parameters can see a speed improvement of ~3x: ``` aaron@tc-lan-adapter ~/g/ruby (inline-new)> cat test.rb class Foo def initialize a:, b:, c: end end i = 0 while i < 10_000_000 Foo.new(a: 1, b: 2, c: 3) Foo.new(a: 1, b: 2, c: 3) Foo.new(a: 1, b: 2, c: 3) i += 1 end aaron@tc-lan-adapter ~/g/ruby (inline-new)> hyperfine "ruby --disable-gems test.rb" "./ruby --disable-gems test.rb" Benchmark 1: ruby --disable-gems test.rb Time (mean ± σ): 3.700 s ± 0.033 s [User: 3.681 s, System: 0.018 s] Range (min … max): 3.636 s … 3.751 s 10 runs Benchmark 2: ./ruby --disable-gems test.rb Time (mean ± σ): 1.182 s ± 0.013 s [User: 1.173 s, System: 0.008 s] Range (min … max): 1.165 s … 1.203 s 10 runs Summary ./ruby --disable-gems test.rb ran 3.13 ± 0.04 times faster than ruby --disable-gems test.rb ``` One factor in the performance increase for keyword arguments is that inlining is able to eliminate the hash allocation when calling “through” the C implementation of `Class#new`: ``` aaron@tc-lan-adapter ~/g/ruby (inline-new)> cat test.rb class Foo def initialize a:, b:, c: end end def allocs x = GC.stat(:total_allocated_objects) yield GC.stat(:total_allocated_objects) - x end def test; allocs { Foo.new(a: 1, b: 2, c: 3) }; end test p test aaron@tc-lan-adapter ~/g/ruby (inline-new)> ruby -v test.rb ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] 2 aaron@tc-lan-adapter ~/g/ruby (inline-new)> ./ruby -v test.rb ruby 3.5.0dev (2025-04-03T13:03:19Z inline-new 567c54208c) +PRISM [arm64-darwin24] 1 ``` ## Memory Increase Of course this patch is not “free”. Inlining the method call adds extra YARV instructions. We estimate this patch increases `new` call sites by about 122 bytes: ``` aaron@tc-lan-adapter ~/g/ruby (inline-new)> cat test.rb require "objspace" class Foo def initialize end end def test Foo.new end puts ObjectSpace.memsize_of(RubyVM::InstructionSequence.of(method(:test))) aaron@tc-lan-adapter ~/g/ruby (inline-new)> ruby -v test.rb ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] 544 aaron@tc-lan-adapter ~/g/ruby (inline-new)> ./ruby -v test.rb ruby 3.5.0dev (2025-04-03T13:03:19Z inline-new 567c54208c) +PRISM [arm64-darwin24] 656 ``` We’ve tested this in Shopify’s monolith, comparing Ruby 3.4.2 and Ruby 3.5+inlining, and it seems to increase total ISEQ memesize by about 3.8mb (roughly 0.5% increase in ISEQ size): ``` irb(main):001> 737191972 - 733354388 => 3837584 ``` However, Ruby 3.5 has more overall ISEQ objects than Ruby 3.4.2: ``` aaron@Aarons-MacBook-Pro ~/Downloads> wc -l sizes-inline.txt 789545 sizes-inline.txt aaron@Aarons-MacBook-Pro ~/Downloads> wc -l sizes-3.4.txt 789479 sizes-3.4.txt ``` We see total heap size as reported by `memsize` to only increase by about 1MB: ``` irb(main):001> 3981075617 - 3979926505 => 1149112 ``` ## Changes to `caller` This patch changes `caller` reporting in the `initialize` method: ``` aaron@tc-lan-adapter ~/g/ruby (inline-new)> cat test.rb require "objspace" class Foo def initialize puts caller end end def test Foo.new end test aaron@tc-lan-adapter ~/g/ruby (inline-new)> ruby -v test.rb ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] test.rb:10:in 'Class#new' test.rb:10:in 'Object#test' test.rb:13:in '<main>' aaron@tc-lan-adapter ~/g/ruby (inline-new)> ./ruby -v test.rb ruby 3.5.0dev (2025-04-03T13:03:19Z inline-new 567c54208c) +PRISM [arm64-darwin24] test.rb:10:in 'Object#test' test.rb:13:in '<main>' ``` As you can see in the above output, the `Class#new` frame is eliminated. I'm not sure if anyone really cares about this frame. We've tested this patch in Shopify's CI, and didn't find any code that depends on this callstack. However, this patch did require [changes to ERB for emitting warnings](https://github.com/ruby/ruby/pull/13080/files#diff-7624f95f521b33…. That said, eliminating the frame also has the side-effect of making some of our allocation tracing tools a little more useful: ``` aaron@tc-lan-adapter ~/g/ruby (inline-new)> cat test.rb require "objspace" class Foo def test Object.new end end ObjectSpace.trace_object_allocations do obj = Foo.new.test puts ObjectSpace.allocation_class_path(obj) puts ObjectSpace.allocation_method_id(obj) end aaron@tc-lan-adapter ~/g/ruby (inline-new)> ruby -v test.rb ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] Class new aaron@tc-lan-adapter ~/g/ruby (inline-new)> ./ruby -v test.rb ruby 3.5.0dev (2025-04-07T19:40:59Z inline-new 2cf0efa18e) +PRISM [arm64-darwin24] Foo test ``` Before inlining, `ObjectSpace` would report the allocation class path and method id as `Class#new` which isn't very helpful. With the inlining patch, we can see that the object is allocated in `Foo#test`. ## Summary I think the overall memory increase is modest, and the change to `caller` is acceptable especially given the performance increase this patch provides. -- https://bugs.ruby-lang.org/

6 11

[ruby-core:121713] [Ruby Misc#21281] DevMeeting-2025-05-08
by mame (Yusuke Endoh) 07 May '25

07 May '25

Issue #21281 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21281: DevMeeting-2025-05-08 https://bugs.ruby-lang.org/issues/21281 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/05/08 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/05/05. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

6 6

[ruby-core:114025] [Ruby master Feature#19744] Namespace on read
by tagomoris (Satoshi TAGOMORI) 06 May '25

06 May '25

Issue #19744 has been reported by tagomoris (Satoshi TAGOMORI). ---------------------------------------- Feature #19744: Namespace on read https://bugs.ruby-lang.org/issues/19744 * Author: tagomoris (Satoshi TAGOMORI) * Status: Open * Priority: Normal ---------------------------------------- # What is the "Namespace on read" This proposes a new feature to define virtual top-level namespaces in Ruby. Those namespaces can require/load libraries (either .rb or native extension) separately from the global namespace. Dependencies of required/loaded libraries are also required/loaded in the namespace. ### Motivation The "namespace on read" can solve the 2 problems below, and can make a path to solve another problem: The details of those motivations are described in the below section ("Motivation details"). #### Avoiding name conflicts between libraries Applications can require two different libraries safely which use the same module name. #### Avoiding unexpected globally shared modules/objects Applications can make an independent/unshared module instance. #### (In the future) Multiple versions of gems can be required Application developers will have fewer version conflicts between gem dependencies if rubygems/bundler will support the namespace on read. ### Example code with this feature ```ruby # your_module module YourModule end # my_module.rb require 'your_module' module MyModule end # example.rb namespace1 = NameSpace.new namespace1.require('my_module') #=> true namespace1::MyModule #=> #<Module:0x00000001027ea650>::MyModule (or #<NameSpace:0x00...>::MyModule ?) namespace1::YourModule # similar to the above MyModule # NameError YourModule # NameError namespace2 = NameSpace.new # Any number of namespaces can be defined namespace2.require('my_module') # Different library "instance" from namespace1 require 'my_module' # require in the global namespace MyModule.object_id != namespace1::MyModule.object_id #=> true namespace1::MyModule.object_id != namespace2::MyModule.object_id ``` The required/loaded libraries will define different "instances" of modules/classes in those namespaces (just like the "wrapper" 2nd argument of `Kernel.load`). This doesn't introduce compatibility problems if all libraries use relative name resolution (without forced top-level reference like `::Name`). # "On read": optional, user-driven feature "On read" is a key thing of this feature. That means: * No changes are required in existing/new libraries (except for limited cases, described below) * No changes are required in applications if it doesn't need namespaces * Users can enable/use namespaces just for limited code in the whole library/application Users can start using this feature step by step (if they want it) without any big jumps. ## Motivation details This feature can solve multiple problems I have in writing/executing Ruby code. Those are from the 3 problems I mentioned above: name conflicts, globally shared modules, and library version conflicts between dependencies. I'll describe 4 scenarios about those problems. ### Running multiple applications on a Ruby process Modern computers have many CPU cores and large memory spaces. We sometimes want to have many separate applications (either micro-service architecture or modular monolith). Currently, running those applications require different processes. It requires additional computation costs (especially in developing those applications). If we have isolated namespaces and can load applications in those namespaces, we'll be able to run apps on a process, with less overhead. (I want to run many AWS Lambda applications on a process in isolated namespaces.) ### Running tests in isolated namespaces Tests that require external libraries need many hacks to: * require a library multiple times * require many different 3rd party libraries into isolated spaces (those may conflict with each other) Software with plugin systems (for example, Fluentd) will get benefit from namespaces. In addition to it, application tests can avoid unexpected side effects if tests are executed in isolated namespaces. ### Safely isolated library instances Libraries may have globally shared states. For example, [Oj](https://github.com/ohler55/oj) has a global `Obj.default_options` object to change the library behavior. Those options may be changed by any dependency libraries or applications, and it changes the behavior of `Oj` globally, unexpectedly. For such libraries, we'll be able to instantiate a safe library instance in an isolated namespace. ### Avoiding dependency hells Modern applications use many libraries, and those libraries require much more dependencies. Those dependencies will cause version conflicts very often. In such cases, application developers should resolve those by updating each libraries, or should just wait for the new release of libraries to conflict those libraries. Sometimes, library maintainers don't release updated versions, and application developers can do nothing. If namespaces can require/load a library multiple times, it also enables to require/load different versions of a library in a process. It requires the support of rubygems, but namespaces should be a good fundamental of it. ## Expected problems ### Use of top-level references In my expectation, `::Name` should refer the top-level `Name` in the global namespace. I expect that `::ENV` should contain the environment variables. But it may cause compatibility problems if library code uses `::MyLibrary` to refer themselves in their deeply nested library code. ### Additional memory consumption An extension library (dynamically linked library) may be loaded multiple times (by `dlopen` for temporarily copied dll files) to load isolated library "instances" if different namespaces require the same extension library. That consumes additional memory. In my opinion, additional memory consumption is a minimum cost to realize loading extension libraries multiple times without compatibility issues. This occurs only when programmers use namespaces. And it's only about libraries that are used in 2 or more namespaces. ### The change of `dlopen` flag about extension libraries To load an extension library multiple times without conflicting symbols, all extensions should stop sharing symbols globally. Libraries referring symbols from other extension libraries will have to change code & dependencies. (About the things about extension libraries, [Naruse also wrote an entry](https://naruse.hateblo.jp/entry/2023/05/22/193411).) # Misc The proof-of-concept branch is here: https://github.com/tagomoris/ruby/pull/1 It's still work-in-progress branch, especially for extension libraries. -- https://bugs.ruby-lang.org/

17 70

[ruby-core:120619] [Ruby master Bug#21030] Bug: #step with Range<ActiveSupport::Duration> behavior broken on Ruby 3.4.1
by johnnyshields (Johnny Shields) 05 May '25

05 May '25

Issue #21030 has been reported by johnnyshields (Johnny Shields). ---------------------------------------- Bug #21030: Bug: #step with Range<ActiveSupport::Duration> behavior broken on Ruby 3.4.1 https://bugs.ruby-lang.org/issues/21030 * Author: johnnyshields (Johnny Shields) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Issue also filed at: https://github.com/rails/rails/issues/54199 ### System configuration **Rails version**: 7.1.5.1 **Ruby version**: 3.3.4 (works) vs 3.4.1 (broken) ### What's broken Calling `#step` then `#to_a` on a `Range` whose beginning/end values are the same is expected to return an `Array` wrapping the `Range`'s singular value. In other words, `(x..x).step(n).to_a` should return `[x]` -- note this is also the same as `(x..x).to_a` The following case breaks on Ruby 3.4.1 related to `ActiveSupport::Duration` class, where it returns an empty array. It works on Ruby 3.3. Both tested with Rails 7.1.5.1. It's very easy to reproduce. I'm unsure if this is a Ruby bug or a Rails bug so I'm filing it in both places. The upgrade of Ruby is what produces the difference. ```ruby require 'active_support/all' # version 7.1.5.1 int = 100 dur = 100.seconds # ActiveSupport/Duration # The bug (dur..dur).step(10).to_a # => Ruby 3.3 returns [100 seconds] - CORRECT # => Ruby 3.4 returns [] - INCORRECT (int..dur).step(10).to_a # => Ruby 3.3 returns [100] - CORRECT # => Ruby 3.4 returns [] - INCORRECT # Note the following cases work correctly on both Ruby versions: (int..int).step(10).to_a #=> [100] (int..dur).to_a #=> [100] # Range with non-equivalent values also works fine on different versions: dur2 = 120.seconds (dur..dur2).step(10).to_a #=> [100 seconds, 110 seconds, 120 seconds] (int..dur2).step(10).to_a #=> [100, 110, 120] ``` -- https://bugs.ruby-lang.org/

6 10

[ruby-core:120855] [Ruby master Bug#21104] Net::HTTP connections failing in Ruby >= 3.4.0 on macOS with Happy Eyeballs enabled
by mjt58 (Mike Thompson) 05 May '25

05 May '25

Issue #21104 has been reported by mjt58 (Mike Thompson). ---------------------------------------- Bug #21104: Net::HTTP connections failing in Ruby >= 3.4.0 on macOS with Happy Eyeballs enabled https://bugs.ruby-lang.org/issues/21104 * Author: mjt58 (Mike Thompson) * Status: Open * ruby -v: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- A project I work on recently upgraded Ruby to 3.4.1 from 3.3.5. Following the upgrade, and when running locally on my Mac, all attempts to connect to an external service within the project over http(s) fail. We use `mise` for managing development tool dependencies, including Ruby, and I am using macOS 15.3. For example running something as simple as: ``` require 'net/http' puts Net::HTTP.get(URI('https://bbc.co.uk')) ``` Will fail with the following stack trace: ``` /path/to/.local/share/mise/installs/ruby/3.4.1/lib/ruby/3.4.0/net/protocol.rb:46:in 'OpenSSL::SSL::SSLSocket#connect_nonblock': Connection reset by peer - SSL_connect (Errno::ECONNRESET) from /path/to/.local/share/mise/installs/ruby/3.4.1/lib/ruby/3.4.0/net/protocol.rb:46:in 'Net::Protocol#ssl_socket_connect' from /path/to/.local/share/mise/installs/ruby/3.4.1/lib/ruby/3.4.0/net/http.rb:1736:in 'Net::HTTP#connect' from /path/to/.local/share/mise/installs/ruby/3.4.1/lib/ruby/3.4.0/net/http.rb:1636:in 'Net::HTTP#do_start' from /path/to/.local/share/mise/installs/ruby/3.4.1/lib/ruby/3.4.0/net/http.rb:1625:in 'Net::HTTP#start' from /path/to/.local/share/mise/installs/ruby/3.4.1/lib/ruby/3.4.0/net/http.rb:1064:in 'Net::HTTP.start' from /path/to/.local/share/mise/installs/ruby/3.4.1/lib/ruby/3.4.0/net/http.rb:824:in 'Net::HTTP.get_response' from /path/to/.local/share/mise/installs/ruby/3.4.1/lib/ruby/3.4.0/net/http.rb:805:in 'Net::HTTP.get' from request.rb:2:in '<main>' ``` I tried different versions of Ruby and confirmed that the issue appears with 3.4.0. After reading the release notes for this version, I tried setting `RUBY_TCP_NO_FAST_FALLBACK=1` and this worked, allowing me to work around the problem. This issue has also been encountered by others, please see: https://github.com/rubygems/rubygems/issues/8390 -- https://bugs.ruby-lang.org/

6 13

[ruby-core:121778] [Ruby Bug#21296] The builds of `RUBY_DEBUG` and `VM_CHECK_MODE` are broken
by hsbt (Hiroshi SHIBATA) 01 May '25

01 May '25

Issue #21296 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21296: The builds of `RUBY_DEBUG` and `VM_CHECK_MODE` are broken https://bugs.ruby-lang.org/issues/21296 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- `RUBY_DEBUG` and `VM_CHECK_MODE` are broken from 4-5 days ago. * https://github.com/ruby/ruby/actions/runs/14731314851/job/41346072323?pr=13… * https://github.com/ruby/ruby/actions/runs/14731314851/job/41346071897?pr=13… ``` /github/workspace/src/vm_core.h:1990: Assertion Failed: rb_current_execution_context:ec == rb_current_ec_noinline() ruby 3.5.0dev (2025-04-29T12:32:24Z pull/13200/merge 22fe2a6945) +PRISM [x86_64-linux] ``` I'm not sure what's root cause for that. But omnibus compilations 8 and 9 are broken since merging https://github.com/ruby/ruby/pull/13080. You can track that results from https://github.com/ruby/ruby/actions/workflows/compilers.yml -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121769] [Ruby Bug#21293] C23/GCC 15 build breakage with rb_define_method() and friends
by alanwu (Alan Wu) 01 May '25

01 May '25

Issue #21293 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #21293: C23/GCC 15 build breakage with rb_define_method() and friends https://bugs.ruby-lang.org/issues/21293 * Author: alanwu (Alan Wu) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- GCC 15 defaults to `-std=gnu23`, which breaks rb_define_method() in some corner cases: ```diff diff --git a/object.c b/object.c index 5a379e9..958f421 100644 --- a/object.c +++ b/object.c @@ -4613,7 +4613,8 @@ InitVM_Object(void) rb_cFalseClass = rb_define_class("FalseClass", rb_cObject); rb_cFalseClass_to_s = rb_fstring_enc_lit("false", rb_usascii_encoding()); rb_vm_register_global_object(rb_cFalseClass_to_s); - rb_define_method(rb_cFalseClass, "to_s", rb_false_to_s, 0); + int zero = 0; + rb_define_method(rb_cFalseClass, "to_s", rb_false_to_s, zero); rb_define_alias(rb_cFalseClass, "inspect", "to_s"); rb_define_method(rb_cFalseClass, "&", false_and, 1); rb_define_method(rb_cFalseClass, "|", false_or, 1); ``` Applying the above is fine prior to C23, but on GCC 15 it triggers a build error: ```text compiling object.c In file included from ./include/ruby/ruby.h:27, from constant.h:13, from object.c:22: object.c: In function 'InitVM_Object': ./include/ruby/internal/anyargs.h:288:135: error: passing argument 3 of 'rb_define_method_m3' from incompatible pointer type [-Wincompatible-pointer-types] 288 | #define rb_define_method(klass, mid, func, arity) RBIMPL_ANYARGS_DISPATCH_rb_define_method((arity), (func))((klass), (mid), (func), (arity)) | ^~~~~~ | | | VALUE (*)(VALUE) {aka long unsigned int (*)(long unsigned int)} object.c:4617:5: note: in expansion of macro 'rb_define_method' 4617 | rb_define_method(rb_cFalseClass, "to_s", rb_false_to_s, kek); | ^~~~~~~~~~~~~~~~ ./include/ruby/internal/anyargs.h:277:21: note: expected 'VALUE (*)(void)' {aka 'long unsigned int (*)(void)'} but argument is of type 'VALUE (*)(VALUE)' {aka 'long unsigned int (*)(long unsigned int)'} 277 | RBIMPL_ANYARGS_DECL(rb_define_method, VALUE, const char *) | ^~~~~~~~~~~~~~~~ ./include/ruby/internal/anyargs.h:252:41: note: in definition of macro 'RBIMPL_ANYARGS_DECL' 252 | RBIMPL_ANYARGS_ATTRSET(sym) static void sym ## _m3(__VA_ARGS__, VALUE(*)(ANYARGS), int); \ | ^~~ object.c:1605:1: note: 'rb_false_to_s' declared here 1605 | rb_false_to_s(VALUE obj) | ^~~~~~~~~~~~~ At top level: cc1: note: unrecognized command-line option '-Wno-self-assign' may have been intended to silence earlier diagnostics cc1: note: unrecognized command-line option '-Wno-parentheses-equality' may have been intended to silence earlier diagnostics cc1: note: unrecognized command-line option '-Wno-constant-logical-operand' may have been intended to silence earlier diagnostics make: *** [Makefile:464: object.o] Error 1 ``` This also happens for C method that takes a large number of arguments. This because in C23 `void foo();` no longers means "foo takes an unspecified number of arguments" anymore, and there is no way to implement a working `ANYARGS` AFAIK. Not something people would run into in practice, I hope. (related: #21286 but this one is not Windows specific) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:121775] [Ruby Bug#21295] ruby/ruby-dev-builder - macos-13 debug build failures, stops GHA master build updates
by MSP-Greg (Greg L) 30 Apr '25

30 Apr '25

Issue #21295 has been reported by MSP-Greg (Greg L). ---------------------------------------- Bug #21295: ruby/ruby-dev-builder - macos-13 debug build failures, stops GHA master build updates https://bugs.ruby-lang.org/issues/21295 * Author: MSP-Greg (Greg L) * Status: Open * ruby -v: master * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- @Eregon [ruby/ruby-dev-builder](https://github.com/ruby/ruby-dev-builder) has issues turned off, which I can understand. It is the repo that creates the Ubuntu & macOS MRI master/head builds used in GHA (GitHub Actions). Recently, there have been test-all failures in the 'macos-13 debug' job. Also, the tests take longer to run than macos-14. I believe macos-13 is x64, macos-14 is arm64. It would certainly be nice to fix the problem. In at least a few workflow runs, it is the only job failure. A more significant issue is that any failure in the workflow's jobs stops a new release from being created. The 'macos-13 debug' jobs have failed on the last two days runs (it . Recently `Set` was updated, I believe it's been a few days, but I don't recall any API changes. I believe no tests were changed/added, but marshalling set was covered in test suites. Hence, that was overlooked, and a subsequent PR/commit fixed it. But, the first commit was done where a new release was created. Since the the 2nd commit was done, all the 'macos-13 debug' jobs have been failing. Hence, it's not available in GHA. So, there are two issues: 1. 'macos-13 debug' is failing test-all 2. ruby/ruby-dev-builder cannot update any master build if one or more of the master builds fail. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:121727] [Ruby Feature#21284] Request: add `Array#pad` method
by MatzFan (Brian Cohen) 30 Apr '25

30 Apr '25

Issue #21284 has been reported by MatzFan (Brian Cohen). ---------------------------------------- Feature #21284: Request: add `Array#pad` method https://bugs.ruby-lang.org/issues/21284 * Author: MatzFan (Brian Cohen) * Status: Open ---------------------------------------- A method to pad an array of arbitrary length with objects up to a specified array size does not currently exist. `Array#fill` does not do this and I therefore propose the following method: ``` ruby class Array def pad(pad_to_length, object = nil) fill(object, size, pad_to_length - size) end end ``` I have provided an [answer](https://stackoverflow.com/a/79591610/4114896) to a Stack Overflow question asking how this can be done in Ruby. I've also explained in a comment on the answer which suggests using `Array#fill` why this does not meet the exact need. -- https://bugs.ruby-lang.org/

3 6