- ruby-core - ml.ruby-lang.org

[ruby-core:125398] [Ruby Bug#22022] Refinement zsuper problems when referenced method changes
by jeremyevans0 (Jeremy Evans) 04 May '26

04 May '26

Issue #22022 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #22022: Refinement zsuper problems when referenced method changes https://bugs.ruby-lang.org/issues/22022 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-03T23:57:21Z master d8d2ed5dc9) +PRISM [x86_64-openbsd7.8] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've found many problems with refinement zsuper methods. Here's one example: ```ruby module M private def a = :a alias a a end class A include M end class B < A end module R refine B do public :a end end using R B.new.a # false() function is unimplemented on this machine (NotImplementedError) ``` Here's another: ```ruby class A private def a = :a end module R refine A do public :a end end using R A.new.a # => :a module M def a = :b end A.prepend M A.new.a # SystemStackError: stack level too deep ``` The problematic cases are in general can be broken down into: * Method being redefined (in same or closer ancestor) * Method being removed * Method being undef-ed (in same or closer ancestor) * Method being overridden by method in included module * Method being overridden by method in prepended module * Method being defined in an included/prepended module at time of refinement In addition to the `NotImplementedError` and `SystemStackError`, there are other cases where incorrect results are given. One possible approach for fixing this is to turn the zsuper methods into regular methods that call super . This fixes all cases that I found. This is not a perfect solution, due to mildly worse performance (I'm guessing) as well as arity/parameters for the method not as helpful. It may possible to avoid these issues by clearing method caches in more cases. However, I think that would require a lot of extra work, since you cannot just clear the method cache for the current class. You would need to clear it for all subclasses, if this is a module, do the same for all classes that include/prepend the module, as well as any subclasses of those classes. Considering the need for refinement zsuper methods is very rare, the performance and arity/parameters issues seem acceptable (to me). Pull request: https://github.com/ruby/ruby/pull/16844 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124655] [Ruby Bug#21856] Nokogiri performance degradation since Ruby 4.0
by ahorek 30 Apr '26

30 Apr '26

Issue #21856 has been reported by ahorek (Pavel Rosický). ---------------------------------------- Bug #21856: Nokogiri performance degradation since Ruby 4.0 https://bugs.ruby-lang.org/issues/21856 * Author: ahorek (Pavel Rosický) * Status: Open * ruby -v: ruby 4.1.0dev (2026-01-31T09:41:30Z master 7ef8c470d2) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Loofah sanitization is noticeably slower ``` Ruby: 3.4.8 Loofah: 2.25.0 Nokogiri: 1.19.0 Iterations: 100000 user system total real Loofah.fragment + scrub!(:prune) 26.091872 0.000000 26.091872 ( 25.110925) Loofah.scrub_fragment(:prune) 25.913185 0.010392 25.923577 ( 24.948464) Nokogiri HTML parse only 3.852690 0.000000 3.852690 ( 3.705930) Ruby: 4.0.0 & 4.0.1 Loofah: 2.25.0 Nokogiri: 1.19.0 Iterations: 100000 user system total real Loofah.fragment + scrub!(:prune) 38.094207 0.041753 38.135960 ( 36.669463) Loofah.scrub_fragment(:prune) 40.168795 0.000045 40.168840 ( 38.561806) Nokogiri HTML parse only 4.012936 0.052024 4.064960 ( 3.913272) Ruby: 4.1.0 (ruby 4.1.0dev (2026-01-31T09:41:30Z master 7ef8c470d2) +PRISM [x86_64-linux]) Loofah: 2.25.0 Nokogiri: 1.19.0 Iterations: 100000 user system total real Loofah.fragment + scrub!(:prune) 39.004228 0.000000 39.004228 ( 37.694873) Loofah.scrub_fragment(:prune) 39.043199 0.031284 39.074483 ( 37.182785) Nokogiri HTML parse only 3.889100 0.010427 3.899527 ( 3.741622) ``` Originally reported https://www.redmine.org/issues/43737 ---Files-------------------------------- benchmark.rb (1002 Bytes) -- https://bugs.ruby-lang.org/

9 14

[ruby-core:125327] [Ruby Bug#22009] ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: with ASAN and DEBUG enabled build
by yahonda (Yasuo Honda) 29 Apr '26

29 Apr '26

Issue #22009 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #22009: ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: with ASAN and DEBUG enabled build https://bugs.ruby-lang.org/issues/22009 * Author: yahonda (Yasuo Honda) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ### Background I am using ruby-head built and deployed by https://github.com/ruby/ruby-dev-builder for my repository. https://github.com/rsim/oracle-enhanced/blob/master/.github/workflows/ruby_… Recently, the `ruby-head` version has not been updated since `ruby 4.1.0dev (2026-03-29T05:57:51Z :detached: f9175a9e5f) +PRISM [aarch64-linux]`. According to the ruby-dev-builder log file: - The last successful build : https://github.com/ruby/ruby-dev-builder/actions/runs/23716940676 - The first failing build :https://github.com/ruby/ruby-dev-builder/actions/runs/23763490942 - The latest failing build : https://github.com/ruby/ruby-dev-builder/actions/runs/24686105004 ### Steps to reproduce ``` mkdir work cd work git clone https://github.com/ruby/ruby.git git clone https://github.com/ruby/ruby-dev-builder.git cd ruby ../ruby-dev-builder/asan_libs.rb \ --prefix=$HOME/.rubies/ruby-asan \ --cc=clang \ --cflags='-fsanitize=address -fno-omit-frame-pointer -ggdb3 -O3' \ --ldflags="-Wl,-rpath=$HOME/.rubies/ruby-asan/lib" \ --makeopts=-j4 export cppflags="-DENABLE_PATH_CHECK=0 -DRUBY_DEBUG=1 -DVM_CHECK_MODE=1 -DUSE_MN_THREADS=0" export optflags="-O3 -fno-omit-frame-pointer" export debugflags="-fsanitize=address -ggdb3" export CC=clang export cflags="-I$HOME/.rubies/ruby-asan/include" export LDFLAGS="-L$HOME/.rubies/ruby-asan/lib -Wl,-rpath=$HOME/.rubies/ruby-asan/lib" export RUBY_TEST_TIMEOUT_SCALE=5 ./autogen.sh ./configure --prefix=$HOME/.rubies/ruby-asan --enable-shared --disable-install-doc --enable-yjit make -j4 && make install make test-spec MSPECOPT="spec/ruby/library/objectspace/dump_all_spec.rb" 2>&1 | tee error.log ``` ### Expected behavior This spec should pass. ### Actual behavior It raises `ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned:` -- https://bugs.ruby-lang.org/

2 4

[ruby-core:125352] [Ruby Bug#22016] ruby segfaults regularly
by wiz (Thomas Klausner) 29 Apr '26

29 Apr '26

Issue #22016 has been reported by wiz (Thomas Klausner). ---------------------------------------- Bug #22016: ruby segfaults regularly https://bugs.ruby-lang.org/issues/22016 * Author: wiz (Thomas Klausner) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-netbsd] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When using ruby 4.0.2 on NetBSD-11.99.5/x86_64, built from pkgsrc, I often get core dumps. Recently it was quite easy to get them using asciidoctor to build the documentation for vms-empire (but that is just one example). Here is the backtrace of the latest coredump: ``` GNU gdb (GDB) 17.1 Copyright (C) 2025 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64--netbsd". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ruby40... ⚠️ warning: exec file is newer than core file. [New process 29975] [New process 316] Core was generated by `ruby40'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007af7bc25f99a in _lwp_kill () from /usr/lib/libc.so.12 [Current thread is 1 (process 29975)] #0 0x00007af7bc25f99a in _lwp_kill () from /usr/lib/libc.so.12 #1 0x00007af7bc926422 in rb_bug_for_fatal_signal (default_sighandler=0x0, sig=sig@entry=11, ctx=ctx@entry=0x7af7a1f6e420, fmt=fmt@entry=0x7af7bca2ec38 "Segmentation fault at %p") at error.c:1135 #2 0x00007af7bc7d2406 in sigsegv (sig=11, info=0x7af7a1f6e3a0, ctx=0x7af7a1f6e420) at signal.c:948 #3 <signal handler called> #4 each_location (x=0x7f7fff7c3000, n=338431, cb=cb@entry=0x7af7bc6b4ef5 <gc_mark_machine_stack_location_maybe>, data=0x0) at gc.c:2682 #5 0x00007af7bc6a955b in each_location_ptr (data=0x0, start=<optimized out>, end=<optimized out>, cb=0x7af7bc6b4ef5 <gc_mark_machine_stack_location_maybe>) at gc.c:2691 #6 each_location_ptr (start=<optimized out>, end=<optimized out>, cb=0x7af7bc6b4ef5 <gc_mark_machine_stack_location_maybe>, data=0x0) at gc.c:2688 #7 rb_gc_mark_machine_context (ec=0x7af7bc023650) at gc.c:2978 #8 mark_current_machine_context (ec=0x7af7bc023650) at gc.c:2958 #9 rb_gc_mark_roots (objspace=<optimized out>, categoryp=0x0) at gc.c:3056 #10 mark_roots (objspace=<optimized out>, categoryp=0x0) at gc/default/default.c:4629 #11 0x00007af7bc6bd047 in gc_marks_start (objspace=0x7af7bc018000, full_mark=<optimized out>) at gc/default/default.c:5815 #12 gc_marks (objspace=0x7af7bc018000, full_mark=<optimized out>) at gc/default/default.c:5831 #13 gc_start (objspace=objspace@entry=0x7af7bc018000, reason=<optimized out>, reason@entry=256) at gc/default/default.c:6516 #14 0x00007af7bc6bdd17 in heap_prepare (objspace=0x7af7bc018000, heap=0x7af7bc018028) at gc/default/default.c:2086 #15 heap_next_free_page (objspace=0x7af7bc018000, heap=0x7af7bc018028) at gc/default/default.c:2301 #16 newobj_cache_miss (objspace=0x7af7bc018000, cache=0x7af7bc000000, heap_idx=0, vm_locked=vm_locked@entry=false) at gc/default/default.c:2408 #17 0x00007af7bc6be719 in newobj_alloc (objspace=<optimized out>, cache=<optimized out>, heap_idx=<optimized out>, vm_locked=false) at gc/default/default.c:2432 #18 rb_gc_impl_new_obj (objspace_ptr=<optimized out>, cache_ptr=<optimized out>, klass=135203969407320, flags=8218, wb_protected=<optimized out>, alloc_size=<optimized out>) at gc/default/default.c:2511 #19 newobj_of (cr=<optimized out>, klass=135203969407320, flags=8218, shape_id=0, wb_protected=<optimized out>, size=<optimized out>) at gc.c:996 #20 0x00007af7bc84fcca in svar_new (obj=<optimized out>) at vm_insnhelper.c:642 #21 lep_svar_set (ec=0x7af7bc023650, lep=0x7af7bbefe6a0, key=key@entry=1, val=val@entry=4) at vm_insnhelper.c:656 #22 0x00007af7bc860c19 in vm_cfp_svar_set (ec=<optimized out>, cfp=<optimized out>, key=1, val=4) at vm.c:2014 #23 0x00007af7bc7983f9 in rb_reg_search_set_match (re=re@entry=135203970164480, str=str@entry=135203969420880, pos=pos@entry=0, reverse=reverse@entry=0, set_backref_str=set_backref_str@entry=-1, set_match=set_match@entry=0x7f7fff7bea60) at re.c:1795 #24 0x00007af7bc798707 in rb_reg_search0 (re=re@entry=135203970164480, str=str@entry=135203969420880, pos=pos@entry=0, reverse=reverse@entry=0, set_backref_str=set_backref_str@entry=-1, match=match@entry=0x7f7fff7bea60) at re.c:1857 #25 0x00007af7bc7ef856 in rb_pat_search0 (pat=pat@entry=135203970164480, str=str@entry=135203969420880, pos=pos@entry=0, set_backref_str=set_backref_str@entry=-1, match=match@entry=0x7f7fff7bea60) at string.c:6167 #26 0x00007af7bc7febcf in str_gsub (argc=<optimized out>, argv=<optimized out>, str=135203969420880, bang=0) at string.c:6352 #27 0x00007af7bc8612a1 in vm_call_cfunc_with_frame_ (ec=0x7af7bc023650, reg_cfp=0x7af7bbffe310, calling=<optimized out>, argc=1, argv=0x7af7bbefe6b0, stack_bottom=0x7af7bbefe6a8) at vm_insnhelper.c:3902 #28 0x00007af7bc865da4 in vm_sendish (ec=0x7af7bc023650, reg_cfp=0x7af7bbffe310, cd=0x7af7a0a0f8b0, block_handler=<optimized out>, method_explorer=<optimized out>) at vm_callinfo.h:450 #29 0x00007af7bc86c200 in vm_exec_core (ec=0x62, ec@entry=0x7af7bc023650) at insns.def:856 #30 0x00007af7bc871288 in vm_exec_loop (ec=<optimized out>, state=<optimized out>, tag=<optimized out>, result=<optimized out>) at vm.c:2825 #31 rb_vm_exec (ec=0x7af7bc023650) at vm.c:2801 #32 0x00007af7bc874d19 in invoke_iseq_block_from_c (ec=<optimized out>, captured=<optimized out>, self=<optimized out>, argc=<optimized out>, argv=<optimized out>, kw_splat=<optimized out>, passed_block_handler=<optimized out>, cref=0x4, is_lambda=<optimized out>, me=0x0) at vm.c:1820 #33 0x00007af7bc87628e in vm_yield_with_cref (ec=<optimized out>, argc=1, argv=0x7f7fff7beec8, kw_splat=0, cref=0x0, is_lambda=0) at vm.c:1865 #34 vm_yield (ec=<optimized out>, argc=1, argv=0x7f7fff7beec8, kw_splat=0) at vm.c:1879 #35 rb_yield_0 (argc=1, argv=0x7f7fff7beec8) at vm_eval.c:1362 #36 rb_yield (val=<optimized out>) at vm_eval.c:1378 #37 0x00007af7bc6c2366 in each_value_i (key=<optimized out>, value=<optimized out>, _=<optimized out>) at hash.c:3033 #38 0x00007af7bc6c3d42 in hash_foreach_iter () at hash.c:1269 #39 0x00007af7bc7ddb73 in st_general_foreach (tab=<optimized out>, func=0x7af7bc6c3d1b <hash_foreach_iter>, replace=0x0, arg=140187723886960, check_p=1) at st.c:1564 #40 0x00007af7bc6c4c9c in hash_foreach_call (arg=140187723886960) at hash.c:1396 #41 0x00007af7bc69a725 in rb_ec_ensure (ec=0x7af7bc023650, b_proc=<optimized out>, data1=<optimized out>, e_proc=0x7af7bc6c224a <hash_foreach_ensure>, data2=135203970494680) at eval.c:1146 #42 0x00007af7bc69a8dc in rb_ensure (b_proc=<optimized out>, data1=<optimized out>, e_proc=<optimized out>, data2=<optimized out>) at eval.c:1163 #43 0x00007af7bc6c734c in rb_hash_foreach (hash=hash@entry=135203970494680, func=func@entry=0x7af7bc6c2345 <each_value_i>, farg=farg@entry=0) at hash.c:1420 #44 0x00007af7bc6c8404 in rb_hash_each_value (hash=135203970494680) at hash.c:3061 #45 0x00007af7bc8612a1 in vm_call_cfunc_with_frame_ (ec=0x7af7bc023650, reg_cfp=0x7af7bbffe3b8, calling=<optimized out>, argc=0, argv=0x7af7bbefe638, stack_bottom=0x7af7bbefe630) at vm_insnhelper.c:3902 #46 0x00007af7bc865da4 in vm_sendish (ec=0x7af7bc023650, reg_cfp=0x7af7bbffe3b8, cd=0x7af7a0ab1c60, block_handler=<optimized out>, method_explorer=<optimized out>) at vm_callinfo.h:450 #47 0x00007af7bc86c200 in vm_exec_core (ec=0x62, ec@entry=0x7af7bc023650) at insns.def:856 #48 0x00007af7bc871288 in vm_exec_loop (ec=<optimized out>, state=<optimized out>, tag=<optimized out>, result=<optimized out>) at vm.c:2825 #49 rb_vm_exec (ec=0x7af7bc023650) at vm.c:2801 #50 0x00007af7bc6fd247 in require_internal (ec=ec@entry=0x7af7bc023650, fname=<optimized out>, fname@entry=135203969759680, exception=exception@entry=1, warn=<optimized out>) at load.c:1341 #51 0x00007af7bc6fd2ef in rb_require_string_internal (fname=135203969759680, resurrect=resurrect@entry=false) at load.c:1451 #52 0x00007af7bc6fdcd8 in rb_require_string (fname=<optimized out>) at load.c:1437 #53 0x00007af7bc8612a1 in vm_call_cfunc_with_frame_ (ec=0x7af7bc023650, reg_cfp=0x7af7bbffe460, calling=<optimized out>, argc=1, argv=0x7af7bbefe5e0, stack_bottom=0x7af7bbefe5d8) at vm_insnhelper.c:3902 #54 0x00007af7bc86b8fd in vm_sendish (ec=<optimized out>, reg_cfp=<optimized out>, cd=<optimized out>, block_handler=<optimized out>, method_explorer=<optimized out>) at vm_callinfo.h:450 #55 vm_exec_core (ec=0x62, ec@entry=0x7af7bc023650) at insns.def:904 #56 0x00007af7bc871288 in vm_exec_loop (ec=<optimized out>, state=<optimized out>, tag=<optimized out>, result=<optimized out>) at vm.c:2825 #57 rb_vm_exec (ec=0x7af7bc023650) at vm.c:2801 #58 0x00007af7bc6fd247 in require_internal (ec=ec@entry=0x7af7bc023650, fname=<optimized out>, fname@entry=135203970210040, exception=exception@entry=1, warn=<optimized out>) at load.c:1341 #59 0x00007af7bc6fd2ef in rb_require_string_internal (fname=135203970210040, resurrect=resurrect@entry=false) at load.c:1451 #60 0x00007af7bc6fdcd8 in rb_require_string (fname=<optimized out>) at load.c:1437 #61 0x00007af7bc8612a1 in vm_call_cfunc_with_frame_ (ec=0x7af7bc023650, reg_cfp=0x7af7bbffe4d0, calling=<optimized out>, argc=1, argv=0x7af7bbefe580, stack_bottom=0x7af7bbefe578) at vm_insnhelper.c:3902 #62 0x00007af7bc86b8fd in vm_sendish (ec=<optimized out>, reg_cfp=<optimized out>, cd=<optimized out>, block_handler=<optimized out>, method_explorer=<optimized out>) at vm_callinfo.h:450 #63 vm_exec_core (ec=0x62, ec@entry=0x7af7bc023650) at insns.def:904 #64 0x00007af7bc871288 in vm_exec_loop (ec=<optimized out>, state=<optimized out>, tag=<optimized out>, result=<optimized out>) at vm.c:2825 #65 rb_vm_exec (ec=0x7af7bc023650) at vm.c:2801 #66 0x00007af7bc7c30ba in ruby_init_prelude () at ruby.c:1779 #67 ruby_opt_init (opt=opt@entry=0x7f7fff7c09d0) at ruby.c:1829 #68 0x00007af7bc7c5038 in ruby_opt_init (opt=0x7f7fff7c09d0) at ruby.c:1799 #69 prism_script (opt=0x7f7fff7c09d0, result=0x7f7fff7c0188) at ruby.c:2234 #70 process_options (argc=6, argc@entry=8, argv=0x7f7fff7c0c08, argv@entry=0x7f7fff7c0bf8, opt=0x7f7fff7c09d0) at ruby.c:2569 #71 0x00007af7bc7c54e0 in ruby_process_options (argc=argc@entry=8, argv=argv@entry=0x7f7fff7c0bf8) at ruby.c:226 #72 0x00007af7bc69b894 in ruby_options (argc=argc@entry=8, argv=argv@entry=0x7f7fff7c0bf8) at eval.c:119 #73 0x0000000000a045e3 in rb_main (argc=8, argv=0x7f7fff7c0bf8) at ./main.c:42 #74 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:62 [?2004h(gdb) quit [?2004l ``` -- https://bugs.ruby-lang.org/

2 4

[ruby-core:124726] [Ruby Feature#21871] Add Module#undef_const
by jeremyevans0 (Jeremy Evans) 29 Apr '26

29 Apr '26

Issue #21871 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21871: Add Module#undef_const https://bugs.ruby-lang.org/issues/21871 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- I propose to add `Module#undef_const`, which would operate for constants similarly to how `undef_method` (and the `undef` keyword) works for methods. When an undefed constant is found during constant lookup, lookup stops, and results in `const_missing` being called (similar to how `undef_method` stops method lookup and results in `method_missing` being called). The expected use for this is for stopping direct access to global constants inside namespaces. For example: ```ruby class DangerousClass; end class SafeClass undef_const :DangerousClass DangerousClass # NameError (const_missing behavior) end DangerousClass # no error ``` You cannot implement this behavior without introducing the equivalent of `Module#undef_const`. The best you can do is define a constant in the namespace that raises later when there is some access to the returned object. However, that approach has significant limitations, since you cannot raise on the lookup, only later when something operates on the returned object: ```ruby class DangerousClass; end class SafeClass DangerousClass = BasicObject.new DangerousClass.foo # NoMethodError DangerousClass::Constant # TypeError def m # doesn't raise, NoMethodError/TypeError occurs potentially much later in unrelated code [DangerousClass] end end ``` As to why it is good to stop direct access to a particular constants inside a namespace, it helps avoid IDOR (insecure direct object reference) security issues, since it pushes you to use a style like: ```ruby # Find a bar related to this foo bar = foo.bars.find { it.id == some_id } ``` As opposed to: ```ruby bar = Bar.find { it.id == some_id && it.foo.id == foo.id } ``` Assuming these are equivalent, the first approach is still better, because it avoids the possibility that a developer can write the following, missing the necessary check that the bar being accessed is related to the foo: ```ruby bar = Bar.find { it.id == some_id } ``` By using `undef_const :Bar` in the namespace, the `Bar.find` approach will not work, and developers will be pushed to use the `foo.bars.find` approach, which enforces safer behavior. I've submitted a pull request that implements this proposal: https://github.com/ruby/ruby/pull/16116 -- https://bugs.ruby-lang.org/

4 4

[ruby-core:125270] [Ruby Misc#22001] Adding TruffleRuby in the CI of all default & bundled gems
by Eregon (Benoit Daloze) 26 Apr '26

26 Apr '26

Issue #22001 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #22001: Adding TruffleRuby in the CI of all default & bundled gems https://bugs.ruby-lang.org/issues/22001 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I would like to add TruffleRuby (i.e. `ruby-version: truffleruby`, the latest release for improved stability) in the CI of all default & bundled gems. I'm tracking the progress in https://github.com/truffleruby/truffleruby/issues/2644. The reason is default & bundled gems are more likely to depend on CRuby internals or CRuby specifics, and have a very large blast readius, and so adding TruffleRuby there would help to avoid such gems breaking unknowingly on TruffleRuby, which has happened a number of times in the past (and similarly on JRuby). The concrete issue is that for some gems without active maintainers (such as in #21922 and more) it can take a (sometimes very) long time to merge the PR adding TruffleRuby in CI. How can we solve this? I also don't want TruffleRuby being in CI to be any kind of burden, so if there is any issue with it more frequent than other Ruby versions in CI, it seems fair to remove it or use `continue-on-error: true` or just ignore the failure. If removing, my only request would be if possible to include `@eregon` in the PR description removing the job so I can take a look. To help keeping CIs green I use [truffleruby-gem-tracker](https://github.com/truffleruby/truffleruby-gem-tra… and I try to check it regularly to fix any failure. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125336] [Ruby Feature#22011] Hash tables with swiss table
by dsh0416 (Delton Ding) 25 Apr '26

25 Apr '26

Issue #22011 has been reported by dsh0416 (Delton Ding). ---------------------------------------- Feature #22011: Hash tables with swiss table https://bugs.ruby-lang.org/issues/22011 * Author: dsh0416 (Delton Ding) * Status: Open ---------------------------------------- This change adds a Swiss-table-inspired probing layer to Ruby's core `st_table`, and shrinks `st_table_entry` from 24 B to 16 B by moving the stored hash into a parallel array. It is built and enabled by default; `--disable-swiss-st` reverts to the original `st.c`. The public ABI of `struct st_table` and the iteration-order guarantee are preserved. ## Motivation Hashes are everywhere in Ruby — instance-variable tables, ivar shapes, constant tables, JSON/HTTP/AR rows, every `params`, every `to_h`. Profiles of Rails-shaped workloads spend a meaningful fraction of CPU inside `st_lookup` and `st_insert`. Two pain points stood out in the upstream implementation: 1. **Probe loops are branch-heavy.** Every step of the perturb chain loads a bin, fetches the entry it points to, compares the full `st_hash_t` (8 B) and only then calls `eql?`. On a miss that is several dependent loads per probe with no way to fast-reject groups of slots in parallel. 2. **`st_table_entry` is 24 B.** The `(hash, key, record)` triple gets one cache line per ~2.5 entries. Iteration and equality scans burn through L1 quickly, and Ruby programs typically hold a *lot* of small-to-mid-sized hashes (so per-table overhead matters). The Swiss-table family of designs (Abseil `flat_hash_map`, Rust `hashbrown`) addresses (1) with a 1-byte-per-slot **control array** that lets a single SIMD/SWAR comparison reject or short-list 8 slots at once. We borrow that idea but keep Ruby's two-array layout (so we don't break ABI or insertion order) and add a third, parallel `ctrl[]` byte array. We then attack (2) by also extracting the hash field out of `st_table_entry` into its own parallel `uint32_t hashes[]` array. --- ## Design ### 1. Three-array layout | array | width | role | | ----------- | --------------------------- | -------------------------------------------------------------------------- | | `entries[]` | 16 B (was 24 B) | insertion-order log of `(key, record)` | | `hashes[]` | 4 B per slot | parallel array of truncated 32-bit hashes (also encodes the tombstone) | | `bins[]` | adaptive 1 / 2 / 4 / 8 B | hash-indexed array of indices into `entries[]` | | `ctrl[]` | 1 B per slot | `H2` (top 7 bits of hash) or `EMPTY (0xff)` / `DELETED (0xfe)` | `entries[]` and `hashes[]` are the same length and addressed by the same index, so iteration and slot reuse stay trivial. `ctrl[]` is the fast-reject filter and lives alongside `bins[]`; only when a `ctrl` byte matches H2 do we load the (now smaller) entry and the parallel hash to confirm the match. SWAR is done on `uint64_t` reads of `ctrl[]` so the per-group cost is a handful of bitwise ops with no SIMD register transfer (which on Apple Silicon was not a win — see "What we tried but didn't keep" below). ### 2. Compact `st_table_entry` Before: ```c struct st_table_entry { st_hash_t hash; /* 8 B */ st_data_t key; /* 8 B */ st_data_t record; /* 8 B */ }; /* 24 B */ ``` After (when `ST_USE_SWISS_BINS` is on, which is the default): ```c struct st_table_entry { st_data_t key; /* 8 B */ st_data_t record; /* 8 B */ }; /* 16 B */ ``` The hash moves into `tab->hashes[i]`, a `uint32_t` (so two slots fit per 8-byte word, four entries per cache line). All access goes through `ST_HASH_AT_PTR` / `ST_HASH_AT_IDX` macros so the same source compiles unchanged when the feature is disabled. The `set_table` variant keeps its original inline-hash layout — it already uses 16 B entries and is not part of `st_table`'s ABI footprint. ### 3. The new hash function (the part that needed the most care) Storing only the low 32 bits of the hash means we can no longer read H2 from the *top* 7 bits of the original `unsigned long` hash, which is what a textbook Swiss design does. Naively recomputing the full 64-bit hash from the key on every rebuild / rehash / `st_shift` / `st_general_foreach` works for correctness but kills insert and rebuild performance — equality+hash for strings is not free. The fix is to derive H2 from a band of the *truncated* 32-bit hash, disjoint from the band that picks the bin: ```c /* bin index: low `bin_power` bits, masked by `bins_mask(tab)` */ hash_bin(uint32_t h, st_table *tab) { return h & bins_mask(tab); } /* H2: bits 25..31 of the same 32-bit hash, never overlaps with */ /* the bin index because bin_power is capped well under 25 in */ /* practice. */ static inline unsigned char st_swiss_h2(st_hash_t hash) { return (unsigned char)((hash >> 25) & 0x7f); } ``` This makes the stored `uint32_t` self-sufficient: every probe reads both the bin index and the H2 byte from the same word, no `do_hash()` call required, and rebuild/rehash/shift/foreach all use `ST_HASH_AT_IDX(tab, i)` instead of recomputing. Two additional details that fall out of the truncation: 1. `normalize_hash_value()` is updated so that `0xFFFFFFFF` (the tombstone marker for the 32-bit hash slot) never collides with a real hash value — if the truncation lands on the reserved value we bump it. The 64-bit reservation is preserved on platforms that compile without `ST_USE_SWISS_BINS`. 2. The `MARK_ENTRY_DELETED` / `DELETED_ENTRY_P` macros now take the table as a parameter so they can read/write the parallel hash slot. ### 4. Prefetch on H2 match When SWAR finds a candidate H2 match in a control group, the next operation is loading the matching `st_table_entry` and the parallel hash word — both of which are in cold cache lines on a miss. We issue `__builtin_prefetch` on both immediately after the match is detected in `find_table_entry_ind` / `find_table_bin_ind` / `find_table_bin_ptr_and_reserve`. On lookup-heavy workloads this hides a meaningful chunk of the L2 latency that the SWAR fast-filter would otherwise expose. ### 5. What we tried but didn't keep * **SSE2 / NEON intrinsics for the group scan.** On Apple Silicon the vector-to-GPR transfer for the match mask cost more than the entire SWAR sequence; on x86_64 the win, if any, was within noise. SWAR is the only shipped backend. * **Recomputing the full 64-bit hash** in rebuild/rehash paths to keep H2 in the high bits. Correct but cost ~5–10 % on insert workloads; superseded by the bit-band trick above. --- ## Results vs `master` Both binaries built from the same tree (`master = 42b3cdc51a`, `swiss = 3c0446847f`), same compiler, same flags. Each script run 5× with `--disable-gems`, best-of-N reported. Memory is `maximum resident set size` from `/usr/bin/time -l` on macOS arm64 (M-class). ### Throughput (lower wall time = better) | benchmark | master (s) | swiss (s) | speedup | | ----------------- | ---------: | --------: | ------: | | aref_int_large | 0.8352 | 0.6862 | **+17.8 %** | | aref_str_large | 0.9915 | 0.8406 | **+15.2 %** | | aref_miss_large | 1.0803 | 0.7896 | **+26.9 %** | | aref_mix_50 | 1.0337 | 0.8201 | **+20.7 %** | | insert_grow | 0.1138 | 0.1105 | +2.9 % | | churn (mixed RW) | 0.0321 | 0.0304 | +5.5 % | | iterate | 0.0566 | 0.0565 | ±0.1 % | Lookups are the headline win — both successful (`+15 % … +20 %`) and missing (`+27 %`), the latter because a missing key now short-circuits on the first SWAR group with no entry/bin loads at all. Inserts and churn are modestly faster because rebuilds no longer call `do_hash`. Iteration is unaffected (it never touched bins or ctrl). ### Memory Process RSS for the benchmark workloads (same runs): | benchmark | master (MB) | swiss (MB) | delta | | ----------------- | ----------: | ---------: | ----: | | insert_grow | 66.62 | 60.44 | **−9.3 %** | | aref_str_large | 15.27 | 15.23 | −0.3 % | | aref_mix_50 | 16.64 | 16.61 | −0.2 % | | churn | 13.19 | 13.03 | −1.2 % | Per-table memory (`ObjectSpace.memsize_of`, sum across many hashes): | workload | master | swiss | delta | | ---------------------------------------- | --------: | --------: | ----------: | | 2 000 hashes × 200 entries | 14.66 MB | 12.11 MB | **−17.4 %** | | 1 hash × 100 000 entries | 4.19 MB | 3.28 MB | **−21.9 %** | The two memory views agree: any workload that holds a meaningful number of entries live (whether one big hash or many small ones) sees double-digit shrinkage from the 24 B → 16 B entry plus the 1 B `ctrl[]` / 4 B `hashes[]` pair, because they together (`5 B` per slot) cost less than the 8 B saved per slot in `entries[]`. Per-table overhead at fewer than ~64 entries is roughly flat; the Swiss path itself only kicks in at `entry_power ≥ 6` (table capacity ≥ 64). ---Files-------------------------------- patch.diff (78 KB) -- https://bugs.ruby-lang.org/

2 10

[ruby-core:125342] [Ruby Bug#22013] Array#| deduplication via eql? breaks when total element count exceeds ~16
by andreyruby (Andrey Glushkov) 25 Apr '26

25 Apr '26

Issue #22013 has been reported by andreyruby (Andrey Glushkov). ---------------------------------------- Bug #22013: Array#| deduplication via eql? breaks when total element count exceeds ~16 https://bugs.ruby-lang.org/issues/22013 * Author: andreyruby (Andrey Glushkov) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [arm64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Problem description The documentation for `Array#|` states: > Returns the union of self and other_array; duplicates are removed; order is preserved; items are compared using `eql?` However, when the total number of elements across both arrays exceeds ~16, deduplication via `eql?` stops working and duplicates are included in the result. ## Reproducible script ```ruby class Item attr_reader :id, :pos def initialize(id, pos:) @id = id @pos = pos end def inspect "item-#{id}-#{pos}" end def eql?(other) id == other.id end end items1 = [Item.new(1, pos: 1)] items2 = [Item.new(1, pos: 2)] # same id — should be treated as duplicate by eql? puts (items1 | items2 ).inspect # 2 total elements puts (items1 * 8 | items2 * 8 ).inspect # 16 total elements puts (items1 * 15 | items2 * 1 ).inspect # 16 total elements puts (items1 * 9 | items2 * 8 ).inspect # 17 total elements ``` ## Actual result ``` [item-1-1] [item-1-1] [item-1-1] [item-1-1, item-1-2] ``` ## Expected result All four lines should return `[item-1-1]`, since `eql?` returns `true` for both items and the documentation makes no mention of any size-dependent behavior. The last line incorrectly returns two elements. The only change is the total element count crossing ~16 — the objects and `eql?` implementation are identical. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:125343] [Ruby Feature#22014] Support `||` and `&&` operations in coverage
by G-Rath (Gareth Jones) 23 Apr '26

23 Apr '26

Issue #22014 has been reported by G-Rath (Gareth Jones). ---------------------------------------- Feature #22014: Support `||` and `&&` operations in coverage https://bugs.ruby-lang.org/issues/22014 * Author: G-Rath (Gareth Jones) * Status: Open ---------------------------------------- https://bugs.ruby-lang.org/issues/13901 added support for branch coverage, but did not include `||` and `&&` branches i.e. ``` def self.even_and_positive(number) number.even? && number >= 0 end ``` Currently, this is considered to be 100% covered so long as it is executed, even though some values won't result in the right hand check being executed. From the comments on the original ticket, it sounds like `||` and `&&` were planned to be supported: > https://bugs.ruby-lang.org/issues/13901?tab=history#note-6 > **marcandre**: > I imagine you are planning on covering ||, &&, &. and ? :, right? > > https://bugs.ruby-lang.org/issues/13901?tab=history#note-7 > **mame**: > ? : has been already supported. Yuichiro has experimentally implemented &. coverage. I think we should support || and && too. > (Formerly, I had no intention of supporting them, but Yuichiro implemented column numbers, so now we will be able to do that.) So I'm hoping this is just something that got forgotten about rather than having a particular unsolved technical challenge. Related: https://github.com/simplecov-ruby/simplecov/issues/921 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125114] [Ruby Feature#21962] Add deep_freeze for recursive freezing
by Eregon (Benoit Daloze) 21 Apr '26

21 Apr '26

Issue #21962 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21962: Add deep_freeze for recursive freezing https://bugs.ruby-lang.org/issues/21962 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- ### Motivation It is common to want some data structure to be immutable, e.g. to ensure it doesn't get mutated by multiple threads. See the first section of #21665 for a more detailed motivation, the summary is there is long-standing demand for it (back to #17145) for many reasons. One way/workaround to do this currently is `Ractor.make_shareable` but its name suggests a Ractor-specific purpose. The functionality of deeply freezing is separate from Ractor and it is generally useful. `Ractor.make_shareable` almost has the right semantics and has been used for years so this proposal largely follows its semantics rather than reinventing the wheel. The semantics also match the `ice_nine` gem, which further illustrates these semantics work well in practice and are expected. ### Examples It freezes deeply: ```ruby config = { db: { host: ENV["HOST"], ports: [5432] }, flags: [:a, :b] }.deep_freeze config.frozen? # => true config[:db].frozen? # => true config[:db][:host].frozen? # => true config[:db][:ports].frozen? # => true ``` Modules and classes are not frozen by `deep_freeze`: ```ruby String.deep_freeze String.frozen? # => false ``` It works for cyclic references: ```ruby a = [] a << a a.deep_freeze a.frozen? # => true ``` It calls `.freeze` on each object: ```ruby class Stats def initialize(samples) @samples = samples @mean = nil end def mean @mean ||= @samples.sum / @samples.size.to_f end def freeze mean super end end s = Stats.new([1.0, 2.0, 3.0]) s.deep_freeze s.mean # => 2.0, would raise FrozenError instead if overridden #freeze was not called ``` ### Background #21665 relaunched the discussion about `deep_freeze` and it was [discussed in a dev meeting](https://github.com/ruby/dev-meeting-log/blob/master/2025/DevMeetin…. @headius has said he won't have time to look at it soon. So I am proposing something concrete which hopefully can be approved as-is. ### Design * Proposed: `Kernel#deep_freeze`. Alternative: `Object.deep_freeze`. * `Kernel#deep_freeze` is consistent with `Kernel#freeze`. * `[a, b, c].deep_freeze` is nicer, more concise and more idiomatic than `Object.deep_freeze([a, b, c])`. * The proposal focuses on semantics; the exact method name and owner can be decided separately. * The return value is the receiver. * `deep_freeze` never freezes modules and classes and does not visit their internal references * Same as `Ractor.make_shareable` and `IceNine.deep_freeze` * No unexpected breakage because a class, its ancestors, their constants, etc all got frozen. * Very easy to explain in the documentation. * If people want to freeze classes/modules (rare case) they can with `.freeze` and have control and can decide whether to freeze the ancestors, constants, class variables, etc. * `deep_freeze` calls `freeze` and ensures every object is frozen * Same as `Ractor.make_shareable` and `IceNine.deep_freeze` * The already well-known hook to e.g. compute lazy caches eagerly, etc * We still check that `.freeze` did freeze the object, and raise a `RuntimeError` if not (same behavior and error message as `Ractor.make_shareable`). * Not a protocol of defining `deep_freeze` in many classes. * That does not work with circular references. * No need to invent a complex protocol when there is an existing working one (calling `.freeze`) which has proven to work well (by being used by `Ractor.make_shareable`). * Handling circular references by maintaining internally a set of visited objects to avoid walking circular references multiple times * As done in `obj_traverse_i` in `ractor.c`. * No expectation for calling `deep_freeze` repeatedly on the same object to be fast * An object flag wouldn't work for this, for the case that `freeze` raises an exception. * If some `freeze` method raises an exception, the exception is propagated. * Same as `Ractor.make_shareable` and `IceNine.deep_freeze` * Some objects visited before the exception may already be frozen, same as `Ractor.make_shareable` (unavoidable because we need to call `freeze` as we traverse the object graph). * `deep_freeze` does not stop at already-frozen objects, because they may still reference unfrozen objects. * No special treatment for shareable objects, they are frozen too. I think this addresses all the points mentioned in the [dev meeting discussion](https://github.com/ruby/dev-meeting-log/blob/master/2025/DevMee… and in #21665 and in #17145. The traversal and freezing behavior closely follows `Ractor.make_shareable`, without introducing new semantics. ### Implementation The implementation in CRuby would be shared with `Ractor.make_shareable`, `ractor.c` already provides `rb_obj_traverse()` which is a great fit to implement this. From a high-level view the implementation works like this: `deep_freeze` recursively traverses the reachable object graph from the receiver. For each visited object: * If it is a `Class` or `Module`, it is not frozen and its internal references are not traversed. * Otherwise, Ruby calls `.freeze` on the object. * After calling `freeze`, Ruby verifies that the object is frozen. If it is not frozen, an exception is raised (same behavior and error message as `Ractor.make_shareable`). * The traversal keeps a visited set to avoid infinite recursion on cycles. ### Non-goals This proposal is focused on defining `deep_freeze` and nothing else: * This proposal does not define a new protocol requiring classes to implement custom recursive logic. * This proposal does not change `Ractor.make_shareable`. * This proposal does not freeze classes or modules. * This proposal does not attempt to define immutability as a broader language concept. ### Compatibility and risk * The proposal adds a new API and does not change existing `freeze` behavior. * It intentionally reuses existing `freeze` overrides on user objects. * It intentionally does not freeze classes/modules to avoid surprising breakage. * Its semantics are close to existing `Ractor.make_shareable`, reducing implementation risk. ### Relation to existing methods * `freeze`: freezes only the receiver (shallow). * `deep_freeze`: recursively freezes reachable objects. * `Ractor.make_shareable`: recursively freezes reachable objects except if they are already shareable. Special handling to make some objects shareable. -- https://bugs.ruby-lang.org/

5 5