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

[ruby-core:121683] [Ruby Bug#21272] Class.new doesn't trigger :class TracePoint
by st0012 (Stan Lo) 09 Feb '26

09 Feb '26

Issue #21272 has been reported by st0012 (Stan Lo). ---------------------------------------- Bug #21272: Class.new doesn't trigger :class TracePoint https://bugs.ruby-lang.org/issues/21272 * Author: st0012 (Stan Lo) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- According to the official [documentation](https://docs.ruby-lang.org/en/master/TracePoint.html#class-T…: > To filter what is traced, you can pass any of the following as events: > > :class > Start a class or module definition. I'd expect `:class` events to be triggered when new classes are defined via `Class.new` as well, but currently that's not the case. Should we either support `Class.new`, or clarify the behaviour in documentation? ### Reproduction ```rb TracePoint.trace(:class) do |tp| puts "Class created at line: #{tp.lineno}" end class Foo; end # Triggers the tracepoint Baz = Class.new # Doesn't trigger the tracepoint # ruby test.rb # Class created at line: 5 ``` -- https://bugs.ruby-lang.org/

3 8

[ruby-core:118784] [Ruby master Feature#20664] Add `before` and `until` options to Enumerator.produce
by knu (Akinori MUSHA) 08 Feb '26

08 Feb '26

Issue #20664 has been reported by knu (Akinori MUSHA). ---------------------------------------- Feature #20664: Add `before` and `until` options to Enumerator.produce https://bugs.ruby-lang.org/issues/20664 * Author: knu (Akinori MUSHA) * Status: Open ---------------------------------------- Enumerator.produce provides a nice way to generate an infinite sequence but is a bit awkward to define how to end a sequence. It lacks a simple and easy way to produce typical finite sequences in an intuitive syntax. This proposal attempts to solve the problem by adding these two options to the method: - `before`: when provided, it is used as a predicate to determine if an iteration should end before a generated value gets yielded. - `until`: when provided, it is used as a predicate to determine if an iteration should end until after a generated value gets yielded. Any value that responds to `to_proc` and returns a `Proc` object is accepted in these options. A typical use case for the `before` option is traversing a tree structure to iterate over the ancestors or following/preceding siblings of a node. The `until` option can be used when there is a clear definition of the "last" value to yield. ```ruby enum = Enumerator.produce(File, before: :nil?, &:superclass) enum.to_a #=> [File, IO, Object, BasicObject] enum = Enumerator.produce(3, until: :zero?, &:pred) enum_to_a #=> [3, 2, 1, 0] ``` ---Files-------------------------------- 0001-Add-before-and-until-options-to-Enumerator.produce.patch (10.7 KB) -- https://bugs.ruby-lang.org/

6 12

[ruby-core:122842] [Ruby Feature#21518] Statistical helpers to `Enumerable`
by Amitleshed (Amit Leshed) 07 Feb '26

07 Feb '26

Issue #21518 has been reported by Amitleshed (Amit Leshed). ---------------------------------------- Feature #21518: Statistical helpers to `Enumerable` https://bugs.ruby-lang.org/issues/21518 * Author: Amitleshed (Amit Leshed) * Status: Open ---------------------------------------- **Summary** I'd like to add two statistical helpers to `Enumerable`: - `Enumerable#average` (arithmetic mean) - `Enumerable#median` Both are small, well-defined operations that many Rubyists re-implement in apps and gems. Providing them in core avoids repeated, ad-hoc code and aligns with `Enumerable#sum`, which Ruby already ships. **Motivation** - These are among the most common “roll-your-own” helpers for arrays/ranges of numbers. - They are conceptually simple, universally useful beyond web/Rails. - Similar to `sum`, they’re primitives for quick data analysis, ETL scripts, CLI tooling, etc. - Including them encourages consistent semantics (what to do with empty sets, mixed numerics, etc.). ## Proposed API & Semantics ```ruby Enumerable#average -> Float or nil Enumerable#median -> Numeric or nil ``` ```ruby [1, 2, 3, 4].average # => 2.5 (1..4).average # => 2.5 [].average # => nil [1, 3, 2].median # => 2 [1, 2, 3, 10].median # => 2.5 (1..6).median # => 3.5 [].median # => nil ``` Ruby implementation ```ruby module Enumerable def average count = 0 total = 0.0 each do |x| raise TypeError, "non-numeric value for average" unless x.is_a?(Numeric) total += x count += 1 end count.zero? ? nil : total / count end def median arr = to_a return nil if arr.empty? arr.each { |x| raise TypeError, "non-numeric value for median" unless x.is_a?(Numeric) } arr.sort! mid = arr.length / 2 arr.length.odd? ? arr[mid] : (arr[mid - 1] + arr[mid]) / 2.0 end end ``` **Upon approval I'm more than willing to implement spec and code in C.** -- https://bugs.ruby-lang.org/

9 12

[ruby-core:121982] [Ruby Bug#21323] irb fails to start with Namespace
by Eregon (Benoit Daloze) 07 Feb '26

07 Feb '26

Issue #21323 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21323: irb fails to start with Namespace https://bugs.ruby-lang.org/issues/21323 * Author: Eregon (Benoit Daloze) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-10T07:50:29Z namespace-on-read-.. bd4f57f96b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` $ irb irb(main):001> 6 * 7 => 42 $ RUBY_NAMESPACE=1 irb /home/eregon/prefix/ruby-master/bin/ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for know issues, etc. /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/did_you_mean/core_ext/name_error.rb:11: warning: irb is not part of the default gems since Ruby 3.5.0. Install irb from RubyGems. /home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/did_you_mean/core_ext/name_error.rb:11: warning: irb is not part of the default gems since Ruby 3.5.0. Install irb from RubyGems. <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:141:in 'Kernel#require': cannot load such file -- irb (LoadError) Did you mean? erb from <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:141:in 'Kernel#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in 'Namespace::Loader#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in '<top (required)>' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Kernel#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Namespace::Loader#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in '<main>' <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require': cannot load such file -- irb (LoadError) Did you mean? erb from <internal:/home/eregon/prefix/ruby-master/lib/ruby/3.5.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in 'Namespace::Loader#require' from /home/eregon/prefix/ruby-master/lib/ruby/gems/3.5.0+0/gems/irb-1.15.2/exe/irb:7:in '<top (required)>' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Kernel#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in 'Namespace::Loader#load' from /home/eregon/.rubies/ruby-master/bin/irb:25:in '<main>' zsh: exit 1 RUBY_NAMESPACE=1 irb ``` -- https://bugs.ruby-lang.org/

3 5

[ruby-core:116028] [Ruby master Feature#20152] mkmf / extconf: Add a proper way to not compile the extension
by byroot (Jean Boussier) 06 Feb '26

06 Feb '26

Issue #20152 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20152: mkmf / extconf: Add a proper way to not compile the extension https://bugs.ruby-lang.org/issues/20152 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context There are various gems that ship with a native extension as a way to speedup part of the gem, but also ship with a pure Ruby version of these methods as a fallback. So they only want to compile the extension if the platform supports it, and if not, just fallback to the slightly slower Ruby version. Right now users rely on one of two hacks to do this. Either they create an empty Makefile, but then still depend on `make` being available, or publish platform specific packages without any extension in them. Examples: - [`bootsnap` skip compilation if not on MRI or TruffleRuby](https://github.com/Shopify/bootsnap/blob/070151f1305f23102365d… - [`erb` has an extension for MRI but then need to publish a `java` version of the gem that doesn't actually contain Java code, just to skip compilation on JRuby](https://github.com/ruby/erb/issues/52) - [`hiredis-client` skips the compilation for Windows and non-MRI rubies](https://github.com/redis-rb/redis-client/blob/1ab081c1d0e47df5d55e0… ### Feature It would be very useful to have some proper first class API to skip compiling the extension. Something like: ```ruby require "mkmf" if RUBY_ENGINE != "ruby" || RUBY_PLATFORM.match?(/mswin/) skip_compilation else # ... end ``` cc @k0kubun @headius -- https://bugs.ruby-lang.org/

10 21

[ruby-core:124359] [Ruby Misc#21804] Getting setup-ruby Earlier
by koic (Koichi ITO) 03 Feb '26

03 Feb '26

Issue #21804 has been reported by koic (Koichi ITO). ---------------------------------------- Misc #21804: Getting setup-ruby Earlier https://bugs.ruby-lang.org/issues/21804 * Author: koic (Koichi ITO) * Status: Open ---------------------------------------- ruby/setup-ruby is commonly used for development in OSS projects and real-world Rails applications. https://github.com/ruby/setup-ruby This is not specific to Ruby 4.0.0. There is often a delay between a Ruby release and the availability of the corresponding version in setup-ruby. setup-ruby is maintained by the ruby organization and may take a few days to become available after a Ruby release. In contrast, ruby-build is maintained by the rbenv organization and tends to become available shortly after a Ruby release. This makes it easier to start using new Ruby versions immediately. If setup-ruby maintained by the ruby organization were released shortly after a Ruby release, users could start using new Ruby versions sooner. It is difficult to determine whether this issue should be registered on bugs.ruby-lang.org. Since setup-ruby is maintained by the ruby organization, this issue is being opened to raise awareness of the situation. If this is not appropriate, please feel free to close it. Thank you for your continued maintenance and for releasing Ruby. -- https://bugs.ruby-lang.org/

9 17

[ruby-core:123681] [Ruby Bug#21669] Thoroughly implement void value expression check
by mame (Yusuke Endoh) 03 Feb '26

03 Feb '26

Issue #21669 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21669: Thoroughly implement void value expression check https://bugs.ruby-lang.org/issues/21669 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: prism * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- A void-value-expression check is a syntax check that raises a `SyntaxError` if an expression that cannot grammatically return a value (a "void value expression," such as a `return` expression) appears in a context where a value is expected (e.g., the right-hand side of an assignment, the argument of a method call, etc.). A typical example rejected by this check is `x = return`. However, it has become clear that this check is incomplete. This ticket summarizes the results of a discussion with @matz at the hackathon before RubyWorld Conference today. ## 1\. Expressions containing branches @matz said that an expression containing branches should be considered a void value expression only if it can be grammatically determined that all possible branches do not return a value. Based on this, both parse.y and prism currently reject the following code with a "void value expression" `SyntaxError`, but it should be accepted: ```ruby x = begin raise return rescue "OK" else return end # Expected: Code parses and executes successfully. # Actual: Rejected with "unexpected void value expression" SyntaxError. ``` Reason: The `rescue` clause can return a value ("OK"), so the entire `begin` expression is not void. Conversely, the following code is currently accepted by both parse.y and prism, but it should be rejected: ```ruby x = begin foo rescue return else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Reason: This expression always does `return`, so it is void whether `foo` raises an exception or not. Furthermore, `case` expressions must also be rejected similarly when all branches are void: ```ruby x = case when 1; return when 2; return else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Note that `if` expressions appear to be implemented correctly as intended: ```ruby x = if rand < 0.5 return else return end # Expected: Rejected with SyntaxError. # Actual: Rejected. (OK!) ``` ## 2\. Statement lists containing a void value expression @matz also said that if a statements node contains a void value expression, the entire statement list should be treated as a void value expression, even if the void expression is not the last one. Therefore, the following code is currently accepted but should be rejected: ```ruby x = begin return "NG" end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` The same applies to branches within other expressions: ```ruby x = if rand < 0.5 return "NG" else return end # Expected: Rejected with SyntaxError. # Actual: Code parses and executes. ``` Note that if a return statement is inside a branch, that statement cannot be considered a void value expression, so the entire expression also cannot be a void value expression. ```ruby x = begin return if true "NG" end # Expected: Code parses and executes. # Actual: Code parses and executes as expected. (OK!) ``` --- This is considered a bug, but if it causes practical compatibility issues, it may be necessary to plan a migration path or revisit the specifications. (Both prism and parse.y need to be fixed, but I'll assign it to the prism team for now.) -- https://bugs.ruby-lang.org/

6 15

[ruby-core:124638] [Ruby Bug#21854] ruby-prof breaks on 4.0.1
by cfis (Charlie Savage) 31 Jan '26

31 Jan '26

Issue #21854 has been reported by cfis (Charlie Savage). ---------------------------------------- Bug #21854: ruby-prof breaks on 4.0.1 https://bugs.ruby-lang.org/issues/21854 * Author: cfis (Charlie Savage) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x64-mswin64_140] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ruby-prof breaks on 4.0.1 with segmentation faults when measuring memory. See: https://github.com/ruby-prof/ruby-prof/actions/runs/21465420365/job/6182646… (note failures for ruby 3.x are some test that fail, not segementation faults). Tracking this down, one test that fails measure memory (see traceback below). That way that works: * Get a tracearg event (https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_profile…) * Get a measurement - time, memory, etc. - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure… * Get the tracearg object - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure… * Call rb_obj_memsize_of - https://github.com/ruby-prof/ruby-prof/blob/master/ext/ruby_prof/rp_measure… * For a T_DATA object in gc.c > case T_DATA: > size += rb_objspace_data_type_memsize(obj); > break; > Then segmentation fault. Running in debugger: ``` RTYPEDDATA_TYPE(obj) 0x332d747365676964 {wrap_struct_name=??? function={dmark=??? dfree=??? dsize=??? ...} parent=??? ...} wrap_struct_name: <Unable to read memory> function: {dmark=??? dfree=??? dsize=??? ...} parent: <Unable to read memory> data: <Unable to read memory> flags: <Unable to read memory> ``` It sure seems like the object that was provide by tracearg has been garbage collected and is no longer valid. Here is the traceback. This is from a MSVC build, but you can see in the gitlab pipelines the same happens on Ubuntu. ```bash -- C level backtrace information ------------------------------------------- C:\WINDOWS\SYSTEM32\ntdll.dll(NtWaitForSingleObject+0x14) [0x00007FF817DA1C44] C:\WINDOWS\System32\KERNELBASE.dll(WaitForSingleObjectEx+0xaf) [0x00007FF814F2BC5F] C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_print_backtrace+0x3e) [0x00007FFEEBB01F92] C:\Source\ruby-4.0.1-mswin\vm_dump.c:1129 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_bugreport+0x223) [0x00007FFEEBB021BB] C:\Source\ruby-4.0.1-mswin\vm_dump.c:1453 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_bug_for_fatal_signal+0x75) [0x00007FFEEB9BE779] C:\Source\ruby-4.0.1-mswin\error.c:1131 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(sigsegv+0x3d) [0x00007FFEEBAFAF91] C:\Source\ruby-4.0.1-mswin\signal.c:948 C:\WINDOWS\System32\ucrtbase.dll(seh_filter_exe+0x84) [0x00007FF81591E8A4] C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(`__scrt_common_main_seh'::`1'::filt$0+0x16) [0x00007FF7B95D1B4C] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:304 C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll(_C_specific_handler+0x9d) [0x00007FFFF400F55D] C:\WINDOWS\SYSTEM32\ntdll.dll(_chkstk+0x9f) [0x00007FF817DA62FF] C:\WINDOWS\SYSTEM32\ntdll.dll(RtlLocateExtendedFeature+0x597) [0x00007FF817C52327] C:\WINDOWS\SYSTEM32\ntdll.dll(KiUserExceptionDispatcher+0x2e) [0x00007FF817DA5C3E] C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_obj_memsize_of+0x1dc) [0x00007FFEEB9A2C8C] C:\Source\ruby-4.0.1-mswin\gc.c:2351 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(measure_memory+0x51) [0x00007FFFA8427161] C:\Source\ruby-prof\ext\ruby_prof\rp_measure_memory.c:23 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_measure+0x1a) [0x00007FFFA8425D8A] C:\Source\ruby-prof\ext\ruby_prof\rp_measurement.c:38 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_event_hook+0x43) [0x00007FFFA842AC23] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:200 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(tp_call_trace+0x26) [0x00007FFEEBA41E12] C:\Source\ruby-4.0.1-mswin\vm_trace.c:1300 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(exec_hooks_body+0x74) [0x00007FFEEBA3FCA4] C:\Source\ruby-4.0.1-mswin\vm_trace.c:457 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_exec_event_hooks+0x4a) [0x00007FFEEBA40326] C:\Source\ruby-4.0.1-mswin\vm_trace.c:543 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_gc_event_hook+0xc1) [0x00007FFEEB99DE35] C:\Source\ruby-4.0.1-mswin\gc.c:241 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(newobj_of+0x17c) [0x00007FFEEB99C348] C:\Source\ruby-4.0.1-mswin\gc.c:1014 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(typed_data_alloc+0xb6) [0x00007FFEEB9A565A] C:\Source\ruby-4.0.1-mswin\gc.c:1102 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_data_typed_object_zalloc+0x3b) [0x00007FFEEB99D877] C:\Source\ruby-4.0.1-mswin\gc.c:1125 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_managed_id_table_create+0x21) [0x00007FFEEBA2AF2D] C:\Source\ruby-4.0.1-mswin\id_table.c:375 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(callable_method_entry_or_negative+0x299) [0x00007FFEEB9C434D] C:\Source\ruby-4.0.1-mswin\vm_method.c:1918 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(callable_method_entry+0x9) [0x00007FFEEB9C4081] C:\Source\ruby-4.0.1-mswin\vm_method.c:1937 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_populate_cc+0x2a) [0x00007FFEEB9E1CF2] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2155 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_search_method_slowpath+0x7d) [0x00007FFEEB9D0D21] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2299 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_search_method_slowpath0+0x20) [0x00007FFEEB9E261C] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:2321 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x14e) [0x00007FFEEB9E2B2E] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6123 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_protect+0x14a) [0x00007FFEEB9B8DFA] C:\Source\ruby-4.0.1-mswin\eval.c:1127 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_profile_instance+0x58) [0x00007FFFA842C128] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:820 C:\Source\ruby-prof\ext\ruby_prof\ruby_prof.so(prof_profile_class+0x2f) [0x00007FFFA842C19F] C:\Source\ruby-prof\ext\ruby_prof\rp_profile.c:845 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_other+0xbc) [0x00007FFEEB9D5154] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3976 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc+0x103) [0x00007FFEEB9D4E67] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:4057 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_method_each_type+0x67b) [0x00007FFEEB9D7503] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:4888 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_method+0x14c) [0x00007FFEEB9D6E68] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:5052 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ary_each+0x7f) [0x00007FFEEBA1A083] C:\Source\ruby-4.0.1-mswin\array.c:2754 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(invoke_block_from_c_bh+0x2eb) [0x00007FFEEB9C688B] C:\Source\ruby-4.0.1-mswin\vm.c:1834 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_yield_with_cref+0x93) [0x00007FFEEB9E41BF] C:\Source\ruby-4.0.1-mswin\vm.c:1874 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_yield+0x55) [0x00007FFEEB9D1125] C:\Source\ruby-4.0.1-mswin\vm_eval.c:1380 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ary_collect+0xa4) [0x00007FFEEBA18F38] C:\Source\ruby-4.0.1-mswin\array.c:3767 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame_+0x14a) [0x00007FFEEB9D52DA] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3904 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_call_cfunc_with_frame+0x29) [0x00007FFEEB9D5189] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:3949 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_sendish+0x163) [0x00007FFEEB9E2B43] C:\Source\ruby-4.0.1-mswin\vm_insnhelper.c:6134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_exec_core+0x1f41) [0x00007FFEEB9DCA85] C:\Source\ruby-4.0.1-mswin\vm_exec.c:101 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_exec+0x101) [0x00007FFEEB9CF7C9] C:\Source\ruby-4.0.1-mswin\vm.c:2801 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(vm_invoke_proc+0x304) [0x00007FFEEB9DF6D8] C:\Source\ruby-4.0.1-mswin\vm.c:1944 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_vm_invoke_proc+0x95) [0x00007FFEEB9CFCE9] C:\Source\ruby-4.0.1-mswin\vm.c:1967 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_proc_call_kw+0x70) [0x00007FFEEBAADD6C] C:\Source\ruby-4.0.1-mswin\proc.c:1134 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(exec_end_procs_chain+0x3d) [0x00007FFEEB9B5B4D] C:\Source\ruby-4.0.1-mswin\eval_jump.c:106 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_exec_end_proc+0x13b) [0x00007FFEEB9B73AF] C:\Source\ruby-4.0.1-mswin\eval_jump.c:122 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_teardown+0x11e) [0x00007FFEEB9B789A] C:\Source\ruby-4.0.1-mswin\eval.c:158 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(rb_ec_cleanup+0x260) [0x00007FFEEB9B6C68] C:\Source\ruby-4.0.1-mswin\eval.c:211 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\x64-vcruntime140-ruby400.dll(ruby_run_node+0x4d) [0x00007FFEEB9B998D] C:\Source\ruby-4.0.1-mswin\eval.c:321 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(wmain+0x52) [0x00007FF7B95D1052] C:\Source\ruby-4.0.1-mswin\main.c:48 C:\msys64\usr\local\ruby-4.0.1-mswin\bin\ruby.exe(__scrt_common_main_seh+0x10c) [0x00007FF7B95D126C] D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 C:\WINDOWS\System32\KERNEL32.DLL(BaseThreadInitThunk+0x17) [0x00007FF816AEE8D7] ``` -- https://bugs.ruby-lang.org/

2 5

[ruby-core:124634] [Ruby Feature#21852] New improved allocator function interface
by byroot (Jean Boussier) 30 Jan '26

30 Jan '26

Issue #21852 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21852: New improved allocator function interface https://bugs.ruby-lang.org/issues/21852 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- When implementing native types with the `TypedData` API, You have to define an allocator function. That function receive the class to allocate and is supposed to return a new instance. ```c /** * This is the type of functions that ruby calls when trying to allocate an * object. It is sometimes necessary to allocate extra memory regions for an * object. When you define a class that uses ::RTypedData, it is typically the * case. On such situations define a function of this type and pass it to * rb_define_alloc_func(). * * @param[in] klass The class that this function is registered. * @return A newly allocated instance of `klass`. */ typedef VALUE (*rb_alloc_func_t)(VALUE klass); ``` ### Current API shortcomings There are a few limitations with the current API. #### Hard to disallow `.allocate` without breaking `#dup` and `#clone`. First, it is frequent for extensions to want to disable `Class#allocate` for their native types via `rb_undef_alloc_func`, as very often allowing uninitialized object would lead to bugs. The problem with `rb_undef_alloc_func` is that the alloc func is also used internally by `dup` and `clone`, so most types that undefine the allocator also prevent object copy without necessarily realizing it. If you want to both disable `Class#allocate` yet still allow copying, you need to entirely implement the `#dup` and `#clone` methods, which is non-trivial and very few types do. One notable exception is `Binding`, which has to implement these two methods: https://github.com/ruby/ruby/blob/bea48adbcacc29cce9536977e15ceba0d65c8a02/… This works for Ruby code, however it doesn't work with C-level `rb_obj_dup(VALUE)`, as used by the Ractor logic to copy objects across ractors. In the case of `Binding` we probably wouldn't allow it anyway, but for other types it may be a problem. #### Can't support objects of variable width When duping or cloning an object of variable width, you need access to the original object to be able to allocate the right slot size. An example of that is `Thread::Backtrace` objects, as evidenced by [Bug #21818]. To support sending exception objects across ractors, we'd need to make `rb_obj_dup()` work for `Thread::Backtrace`, but to correctly duplicate a backtrace, the allocator needs to know the size. ### Proposed new API I'd like to propose a new API for defining allocators: ```ruby typedef VALUE (*rb_copy_alloc_func_t)(VALUE klass, VALUE other); ``` In addition to the class to allocate, the function also receives the instance to copy. When called by `Class#allocate`, the `other` argument is set to `Qundef`. Example usage: ```c static VALUE backtrace_alloc(VALUE klass, VALUE other) { rb_backtrace_t *bt; if (UNDEF_P(other)) { // Regular alloc return TypedData_Make_Struct(klass, rb_backtrace_t, &backtrace_data_type, bt); } else { // Copy rb_backtrace_t *other_bt; TypedData_Get_Struct(other, rb_backtrace_t, &backtrace_data_type, other_bt); VALUE self = backtrace_alloc_capa(other_bt->backtrace_size, &bt); bt->backtrace_size = other_bt->backtrace_size; MEMCPY(bt->backtrace, other_bt->backtrace, rb_backtrace_location_t, other_bt->backtrace_size); return self; } } ``` ### Backward compatibility Older-style allocator can keep being supported as long as we wish. The one backward potential compatibility concern is third party code that calls `rb_alloc_func_t rb_get_alloc_func(VALUE klass);`. As its documentation suggest, there's not much valid use case for it, but regardless we can keep supporting it by returning a "jump function". See `copy_allocator_adapter`: https://github.com/ruby/ruby/pull/15795/changes#diff-884a5a8a369ef1b4c7597e… ### Opportunity for more changes? I was discussing this new interface with @ko1 and it appears that the current allocator interface may also be a limitation for Ractors and Ractor local GC. i.e. it might be useful to let the allocator function know that we're copying from one Ractor to another. But I know to little about Ractor local GC to make a proposition here, so I will let @ko1 make suggestions. ### Implementation I implemented this idea in https://github.com/ruby/ruby/pull/15795, to solve [Bug #21818]. It could remain a purely private API, but I think it would make sense to expose it. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:124635] [Ruby Feature#21853] Make Embedded TypedData a public API
by byroot (Jean Boussier) 30 Jan '26

30 Jan '26

Issue #21853 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21853: Make Embedded TypedData a public API https://bugs.ruby-lang.org/issues/21853 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- As part of Ruby 3.3, we added a private `RUBY_TYPED_EMBEDDABLE` flag to the `TypedData` API to allow `TypedData` to use variable width allocation. Technically, we inadvertently exposed that flag in public headers so third party extensions can make use of it, but it's not considered public API as it's not documented, so it would be a poor decision. This API has both memory and speed benefits as it allow to avoid some `malloc/free` churn, reduce pointer chasing, etc. For instance, when we converted `Time` to be embedded, it improved allocation performance by 30% and also reduced memory usage by 20%: https://github.com/ruby/ruby/commit/aa6642de630cfc10063154d84e45a7bff30e9103 I believe numerous third party native extensions could benefit from it (I would certainly make use of it in `ruby/json`), now that we used it internally for several years, I'd like to work on making it a public API for Ruby 4.1 -- https://bugs.ruby-lang.org/

2 4