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

[ruby-core:116949] [Ruby master Misc#20303] Troubleshooting Guide for Common Issues with GMC Acadia
by adamrojas (Adam Rojas) 23 Jun '26

23 Jun '26

Issue #20303 has been reported by adamrojas (Adam Rojas). ---------------------------------------- Misc #20303: Troubleshooting Guide for Common Issues with GMC Acadia https://bugs.ruby-lang.org/issues/20303 * Author: adamrojas (Adam Rojas) * Status: Open ---------------------------------------- Owning a GMC Acadia brings numerous benefits, yet like any vehicle, it may encounter issues. In this guide, we’ll delve into common problems reported by GMC Acadia owners and offer effective solutions. ![Troubleshooting Guide for Common Issues with GMC Acadia](https://autorepairandservice.files.wordpress.com/2024/02/troublesho… Whether you’re dealing with transmission faults, engine light codes, or other issues, we’ve got you covered. ## **Troubles with Transmission and Check Engine Light:** ![Troubles with Transmission and Check Engine Light](https://autorepairandservice.files.wordpress.com/2024/02/troubles-wi… One significant challenge faced by GMC Acadia owners revolves around transmission faults, often accompanied by the illumination of the check engine light. This issue, reported by numerous individuals, demands prompt attention to prevent further complications. Seeking assistance from experienced professionals is recommended to diagnose and address these transmission-related concerns effectively, ensuring the continued reliability and performance of your vehicle. ## **Interpreting Check Engine Light Codes:** ![Interpreting Check Engine Light Codes](https://autorepairandservice.files.wordpress.com/2024/02/interpretin… Another common issue encountered by GMC Acadia owners involves the activation of the check engine light, often accompanied by specific diagnostic trouble codes (DTCs). Understanding these codes is essential for identifying underlying issues promptly. Seeking assistance from a qualified mechanic for thorough diagnostics and appropriate remedies is advised to prevent potential engine damage and ensure continued vehicle reliability. ## **Addressing Gas Cap Concerns and Check Engine Light Illumination:** ![Addressing Gas Cap Concerns and Check Engine Light Illumination](https://autorepairandservice.files.wordpress.com/2024/02/addr… Another area of concern for GMC Acadia owners involves issues related to the gas cap, which can lead to the illumination of the check engine light. This problem, while less common, should not be overlooked. It’s important to ensure the gas cap is securely tightened to prevent evaporation and maintain proper fuel system pressure. If the check engine light persists after verifying the gas cap’s tightness, seeking assistance from a qualified technician is advisable to diagnose and resolve any underlying issues effectively. ## **Navigating GMC Acadia Electrical Issues:** ![Navigating GMC Acadia Electrical Issues](https://autorepairandservice.files.wordpress.com/2024/02/navigating… Electrical problems can pose significant challenges for GMC Acadia owners, affecting various systems within the vehicle. These issues might manifest as malfunctioning lights, power window failures, intermittent electrical failures, or battery drainage concerns. Addressing electrical problems promptly is crucial to prevent further complications and ensure the safety and functionality of your Acadia. Seeking assistance from experienced technicians equipped with diagnostic tools and expertise in automotive electrical systems is essential for accurately identifying and resolving these issues, restoring your vehicle’s performance and reliability. ## **Essential Maintenance Tasks for GMC Acadia Owners:** ![Essential Maintenance Tasks for GMC Acadia Owners](https://autorepairandservice.files.wordpress.com/2024/02/essential-… Beyond adhering to scheduled maintenance, there are fundamental tasks that every GMC Acadia owner should prioritize. These include: **1. Regular Brake Fluid Flushes:** To uphold braking effectiveness, it’s crucial to schedule regular brake fluid flushes. This process helps prevent contaminants from compromising the brake system’s performance, ensuring optimal safety on the road. **2. Transmission Inspections:** Regular inspections of the transmission are essential for early detection of potential issues. By identifying any signs of wear or malfunction early on, owners can mitigate the risk of costly repairs and ensure smooth operation of their Acadia. **3. Coolant Inspections:** Preventing overheating is vital for maintaining engine health. Regular coolant inspections help owners monitor coolant levels and quality, ensuring proper engine temperature regulation and preventing potential damage due to overheating. **4. Spark Plug Replacements:** Spark plugs play a critical role in engine performance by igniting the air-fuel mixture in the cylinders. Replacing worn-out spark plugs at recommended intervals helps maintain fuel efficiency, prevent misfires, and ensure optimal engine performance. ## **Expert Tips for GMC Acadia Owners:** ![Expert Tips for GMC Acadia Owners](https://autorepairandservice.files.wordpress.com/2024/02/expert-tip… Routine inspections and preventive measures are key to maintaining your GMC Acadia’s performance and longevity. Beyond addressing specific issues and adhering to maintenance schedules, here are some expert tips to keep your vehicle running smoothly: **1. Driving Habits Matter:** Be mindful of your driving habits to minimize wear and tear on your Acadia. Avoid sudden acceleration or braking whenever possible, and practice smooth, gradual maneuvers to reduce strain on the engine, transmission, and other vital components. **2. Stay Informed and Educated:** Stay updated on recalls, service bulletins, and manufacturer recommendations for your GMC Acadia. Joining online forums or communities dedicated to GMC owners can provide valuable insights and tips from fellow enthusiasts and experts. Keeping yourself informed empowers you to make informed decisions about your vehicle’s care and maintenance. By incorporating these expert tips into your maintenance routine, you can ensure that your GMC Acadia remains reliable, efficient, and enjoyable to drive for miles to come. ## **Conclusion:** Being aware of common GMC Acadia issues and following proper maintenance practices can ensure trouble-free ownership. Promptly addressing problems through professional diagnosis and repair, along with adhering to recommended maintenance intervals, can help maintain a reliable and enjoyable driving experience. Thank you for reading this post. If you're looking for a car specialist to opt for a [cheap plastic bumper repair in Manchester](https://servicemycar.com/uk/services/car-bumper-repair-manchest…. So, you can connect with Service My Car and get the best car dent service at a very reasonable price. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125141] [Ruby Bug#21967] `vm_call_cfunc: cfp consistency error` while requiring `nkf.so`
by byroot (Jean Boussier) 23 Jun '26

23 Jun '26

Issue #21967 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21967: `vm_call_cfunc: cfp consistency error` while requiring `nkf.so` https://bugs.ruby-lang.org/issues/21967 * Author: byroot (Jean Boussier) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I'm unfortunately unable to reproduce this consistently. It does happen a few times a day on our production servers, and I have a few core dumps around for investigation if needed. The crash is always while loading `nknf.so`. I'm unfortunately not familiar enough with `cfp` to investigate this much further myself. ``` <PATH>/vendor/bundle/ruby/4.0.0/gems/nkf-0.2.0/lib/nkf.so: [BUG] vm_call_cfunc: cfp consistency error (0x0000ffff80779830, 0x0000ffff807797f8) ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [aarch64-linux] -- Control frame information ----------------------------------------------- c:0032 p:---- s:0172 e:000171 l:y b:0001 TOP [FINISH] c:0031 p:---- s:0169 e:000168 l:y b:---- CFUNC :require c:0030 p:0033 s:0164 e:000163 l:n b:---- BLOCK <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bu c:0029 p:0145 s:0158 e:000157 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/boots c:0028 p:0026 s:0149 e:000148 l:y b:0001 TOP <PATH>/vendor/bundle/ruby/4.0.0/gems/nkf-0 [FINISH] c:0027 p:---- s:0146 e:000145 l:y b:---- CFUNC :require c:0026 p:0033 s:0141 e:000140 l:n b:---- BLOCK <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bu c:0025 p:0145 s:0135 e:000134 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/boots c:0024 p:0011 s:0126 e:000125 l:y b:0001 TOP <PATH>/vendor/bundle/ruby/4.0.0/gems/mecha [FINISH] c:0023 p:---- s:0123 e:000122 l:y b:---- CFUNC :require c:0022 p:0033 s:0118 e:000117 l:n b:---- BLOCK <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bu c:0021 p:0145 s:0112 e:000111 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/boots c:0020 p:0265 s:0103 e:000102 l:y b:0001 TOP <PATH>/vendor/bundle/ruby/4.0.0/gems/mecha [FINISH] c:0019 p:---- s:0100 e:000099 l:y b:---- CFUNC :require c:0018 p:0011 s:0095 e:000094 l:y b:0001 METHOD <internal:<PATH>/vendor/ruby-4.0.2/lib/rub c:0017 p:0033 s:0089 e:000088 l:n b:---- BLOCK <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bu c:0016 p:0024 s:0083 e:000082 l:n b:---- BLOCK <PATH>/vendor/bundle/ruby/4.0.0/gems/bundl [FINISH] c:0015 p:---- s:0077 e:000076 l:y b:---- CFUNC :each c:0014 p:0027 s:0073 e:000072 l:n b:---- BLOCK <PATH>/vendor/bundle/ruby/4.0.0/gems/bundl [FINISH] c:0013 p:---- s:0069 e:000068 l:y b:---- CFUNC :each c:0012 p:0042 s:0065 e:000064 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/bundl c:0011 p:0013 s:0059 e:000058 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/bundl c:0010 p:0117 s:0054 e:000053 l:y b:0001 TOP <PATH>/config/application.rb:25 [FINISH] c:0009 p:---- s:0051 e:000050 l:y b:---- CFUNC :require_relative c:0008 p:0005 s:0046 e:000045 l:y b:0001 TOP <PATH>/config/environment.rb:2 [FINISH] c:0007 p:---- s:0043 e:000042 l:y b:---- CFUNC :require c:0006 p:0033 s:0038 e:000037 l:n b:---- BLOCK <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bu c:0005 p:0145 s:0032 e:000031 l:y b:0001 METHOD <PATH>/vendor/bundle/ruby/4.0.0/gems/boots c:0004 p:0011 s:0023 e:000022 l:y b:0001 TOP <PATH>/gems/intercom-sqs/exe/intercom-sqs: [FINISH] c:0003 p:---- s:0011 e:000010 l:y b:---- CFUNC :load c:0002 p:0017 s:0006 e:000005 l:n b:---- EVAL bin/intercom-sqs:6 [FINISH] c:0001 p:0000 s:0003 E:001b40 l:y b:---- DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- bin/intercom-sqs:6:in '<main>' bin/intercom-sqs:6:in 'load' <PATH>/gems/intercom-sqs/exe/intercom-sqs:6:in '<main>' <PATH>/vendor/bundle/ruby/4.0.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' <PATH>/config/environment.rb:2:in '<main>' <PATH>/config/environment.rb:2:in 'require_relative' <PATH>/config/application.rb:25:in '<main>' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler.rb:213:in 'require' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler/runtime.rb:52:in 'require' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler/runtime.rb:52:in 'each' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler/runtime.rb:58:in 'block in require' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler/runtime.rb:58:in 'each' <PATH>/vendor/bundle/ruby/4.0.0/gems/bundler-4.0.8/lib/bundler/runtime.rb:63:in 'block (2 levels) in require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' <internal:<PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/rubygems/core_ext/kernel_require.rb>:37:in 'require' <internal:<PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/rubygems/core_ext/kernel_require.rb>:37:in 'require' <PATH>/vendor/bundle/ruby/4.0.0/gems/mechanize-2.10.0/lib/mechanize.rb:1387:in '<main>' <PATH>/vendor/bundle/ruby/4.0.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' <PATH>/vendor/bundle/ruby/4.0.0/gems/mechanize-2.10.0/lib/mechanize/util.rb:3:in '<main>' <PATH>/vendor/bundle/ruby/4.0.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' <PATH>/vendor/bundle/ruby/4.0.0/gems/nkf-0.2.0/lib/nkf.rb:5:in '<main>' <PATH>/vendor/bundle/ruby/4.0.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in 'require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'block (2 levels) in replace_require' <PATH>/vendor/ruby-4.0.2/lib/ruby/4.0.0/bundled_gems.rb:60:in 'require' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_print_backtrace+0x8) [0xaaaab1d0964c] /ruby-4.0.2/vm_dump.c:1105 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_bugreport) /ruby-4.0.2/vm_dump.c:1450 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_bug_without_die_internal+0x70) [0xaaaab1821640] /ruby-4.0.2/error.c:1098 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_bug) /ruby-4.0.2/error.c:1116 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_check_ints+0x0) [0xaaaab19edc54] /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_check_ints) /ruby-4.0.2/vm_core.h:2256 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_pop_frame) /ruby-4.0.2/vm_insnhelper.c:452 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_pop_frame) /ruby-4.0.2/vm_insnhelper.c:461 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3906 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_symbol+0x32c) [0xaaaab19fed34] /ruby-4.0.2/vm_insnhelper.c:4403 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(load_iseq_eval+0x3c) [0xaaaab18a1b44] /ruby-4.0.2/load.c:774 <PATH>/vendor/ruby-4.0.2/bin/ruby(require_internal) /ruby-4.0.2/load.c:1341 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string_internal+0x3c) [0xaaaab18a1f8c] /ruby-4.0.2/load.c:1451 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string) /ruby-4.0.2/load.c:1437 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_f_require) /ruby-4.0.2/load.c:1048 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_symbol+0x32c) [0xaaaab19fed34] /ruby-4.0.2/vm_insnhelper.c:4403 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(load_iseq_eval+0x3c) [0xaaaab18a1b44] /ruby-4.0.2/load.c:774 <PATH>/vendor/ruby-4.0.2/bin/ruby(require_internal) /ruby-4.0.2/load.c:1341 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string_internal+0x3c) [0xaaaab18a1f8c] /ruby-4.0.2/load.c:1451 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string) /ruby-4.0.2/load.c:1437 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_f_require) /ruby-4.0.2/load.c:1048 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_symbol+0x32c) [0xaaaab19fed34] /ruby-4.0.2/vm_insnhelper.c:4403 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(load_iseq_eval+0x3c) [0xaaaab18a1b44] /ruby-4.0.2/load.c:774 <PATH>/vendor/ruby-4.0.2/bin/ruby(require_internal) /ruby-4.0.2/load.c:1341 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string_internal+0x3c) [0xaaaab18a1f8c] /ruby-4.0.2/load.c:1451 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string) /ruby-4.0.2/load.c:1437 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_f_require) /ruby-4.0.2/load.c:1048 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_alias+0x8c) [0xaaaab19fe90c] /ruby-4.0.2/vm_insnhelper.c:4297 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec+0x188) [0xaaaab19fc3f0] /ruby-4.0.2/vm.c:2798 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_yield+0xd0) [0xaaaab1a0131c] /ruby-4.0.2/vm.c:1871 <PATH>/vendor/ruby-4.0.2/bin/ruby(RB_FL_TEST_RAW+0x0) [0xaaaab1bf8968] /ruby-4.0.2/array.c:2754 <PATH>/vendor/ruby-4.0.2/bin/ruby(RB_FL_ANY_RAW) ./include/ruby/internal/fl_type.h:514 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_array_len) ./include/ruby/internal/core/rarray.h:259 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_ary_each) /ruby-4.0.2/array.c:2753 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0x108) [0xaaaab1a0b9f8] /ruby-4.0.2/insns.def:856 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_yield+0xd0) [0xaaaab1a0131c] /ruby-4.0.2/vm.c:1871 <PATH>/vendor/ruby-4.0.2/bin/ruby(RB_FL_TEST_RAW+0x0) [0xaaaab1bf8968] /ruby-4.0.2/array.c:2754 <PATH>/vendor/ruby-4.0.2/bin/ruby(RB_FL_ANY_RAW) ./include/ruby/internal/fl_type.h:514 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_array_len) ./include/ruby/internal/core/rarray.h:259 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_ary_each) /ruby-4.0.2/array.c:2753 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0x108) [0xaaaab1a0b9f8] /ruby-4.0.2/insns.def:856 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(load_iseq_eval+0x3c) [0xaaaab18a1b44] /ruby-4.0.2/load.c:774 <PATH>/vendor/ruby-4.0.2/bin/ruby(require_internal) /ruby-4.0.2/load.c:1341 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string_internal+0x58) [0xaaaab18a1e20] /ruby-4.0.2/load.c:1451 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec+0x188) [0xaaaab19fc3f0] /ruby-4.0.2/vm.c:2798 <PATH>/vendor/ruby-4.0.2/bin/ruby(load_iseq_eval+0x3c) [0xaaaab18a1b44] /ruby-4.0.2/load.c:774 <PATH>/vendor/ruby-4.0.2/bin/ruby(require_internal) /ruby-4.0.2/load.c:1341 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string_internal+0x3c) [0xaaaab18a1f8c] /ruby-4.0.2/load.c:1451 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_require_string) /ruby-4.0.2/load.c:1437 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_f_require) /ruby-4.0.2/load.c:1048 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_symbol+0x32c) [0xaaaab19fed34] /ruby-4.0.2/vm_insnhelper.c:4403 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_loop+0x68) [0xaaaab19fc734] /ruby-4.0.2/vm.c:2825 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec) /ruby-4.0.2/vm.c:2804 <PATH>/vendor/ruby-4.0.2/bin/ruby(raise_load_if_failed+0x0) [0xaaaab18a108c] /ruby-4.0.2/load.c:851 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_load_internal) /ruby-4.0.2/load.c:853 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_f_load+0x84) [0xaaaab18a112c] /ruby-4.0.2/load.c:893 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_cfp_consistent_p+0x0) [0xaaaab19edb00] /ruby-4.0.2/vm_insnhelper.c:3902 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_call_cfunc_with_frame_) /ruby-4.0.2/vm_insnhelper.c:3904 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_sendish+0xc4) [0xaaaab19f3750] /ruby-4.0.2/vm_insnhelper.c:6124 <PATH>/vendor/ruby-4.0.2/bin/ruby(vm_exec_core+0xa4) [0xaaaab1a0b994] /ruby-4.0.2/insns.def:904 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_vm_exec+0x188) [0xaaaab19fc3f0] /ruby-4.0.2/vm.c:2798 <PATH>/vendor/ruby-4.0.2/bin/ruby(rb_ec_exec_node+0x8c) [0xaaaab1824c4c] /ruby-4.0.2/eval.c:283 <PATH>/vendor/ruby-4.0.2/bin/ruby(ruby_run_node+0x3c) [0xaaaab182716c] /ruby-4.0.2/eval.c:321 <PATH>/vendor/ruby-4.0.2/bin/ruby(main+0x70) [0xaaaab1821b30] ./main.c:42 ``` -- https://bugs.ruby-lang.org/

2 5

[ruby-core:124288] [Ruby Bug#21790] `Socket.getaddrinfo` hangs after `fork()` on macOS 26.1 (Tahoe) for IPv4-only hosts
by adamoffat (Adam Moffat) 17 Jun '26

17 Jun '26

Issue #21790 has been reported by adamoffat (Adam Moffat). ---------------------------------------- Bug #21790: `Socket.getaddrinfo` hangs after `fork()` on macOS 26.1 (Tahoe) for IPv4-only hosts https://bugs.ruby-lang.org/issues/21790 * Author: adamoffat (Adam Moffat) * Status: Open * ruby -v: 3.3.8 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby's `Socket.getaddrinfo` hangs indefinitely in forked child processes on macOS 26.1 (Tahoe) when resolving IPv4-only hostnames. This is a regression that does not occur on macOS 15.x (Sonoma) or earlier. **Ruby version:** ruby 3.3.8 (2025-04-09 revision b200bad6cd) [arm64-darwin24] Also confirmed this affects Ruby 3.2.6 and 3.4.1. **Reproducible script:** ``` ruby require "socket" require "timeout" puts "Ruby #{RUBY_VERSION} on #{RUBY_PLATFORM}" Socket.getaddrinfo("api.segment.io", 443, nil, :STREAM) puts "Parent: DNS completed" pid = fork do puts "Child: Attempting DNS resolution..." begin Timeout.timeout(90) do Socket.getaddrinfo("api.segment.io", 443, nil, :STREAM) end puts "Child: SUCCESS" exit 0 rescue Timeout::Error puts "Child: FAILED - hung for 90 seconds" exit 1 end end Process.wait(pid) ``` **Note:** Remove the `Timeout.timeout(90)` wrapper to observe the hang indefinitely. The timeout is included only to allow the script to exit for testing purposes. **Result of reproduce process:** ``` Ruby 3.3.8 on arm64-darwin24 Parent: DNS completed Child: Attempting DNS resolution... Child: FAILED - hung for 90 seconds ``` The child process hangs with one thread consuming 100% CPU. Expected result: The child process should complete DNS resolution successfully, as it does on macOS 15.x and earlier. **Analysis:** Stack trace shows: Main thread: Blocked in `wait_getaddrinfo` → `_pthread_cond_wait` DNS thread: Spinning in `_gai_nat64_second_pass` → `nw_path_access_agent_cache` → `_os_log_preferences_refresh` → `SIGSEGV` The crash occurs in macOS's NAT64 synthesis code path. Ruby's signal handler catches the `SIGSEGV` but cannot recover, causing the DNS thread to spin. **Key observations:** - Only affects IPv4-only hosts. Hosts with IPv6 (like google.com) work correctly. - Using `AF_INET` instead of `AF_UNSPEC` works. `Socket.getaddrinfo("api.segment.io", 443, Socket::AF_INET, :STREAM)` succeeds. - Python is not affected. Python calls `getaddrinfo()` synchronously without a background thread. - Parent must do DNS before fork. If the parent has not called getaddrinfo(), the child works correctly. **Workaround:** - Use `resolv-replace` to bypass the native DNS resolver: `require "resolv-replace"` **Impact:** This breaks all Ruby applications using pre-forking worker models (Resque, Unicorn, Puma, Sidekiq, Passenger) on macOS Tahoe. **Apple Bug Report:** Filed with Apple as Feedback Assistant #FB21364061 ---Files-------------------------------- stack_trace.txt (66.6 KB) ruby_dns_fork_bug.rb (1.02 KB) -- https://bugs.ruby-lang.org/

2 9

[ruby-core:115165] [Ruby master Bug#19972] Install default/bundled gems into dedicated directories
by vo.x (Vit Ondruch) 16 Jun '26

16 Jun '26

Issue #19972 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19972: Install default/bundled gems into dedicated directories https://bugs.ruby-lang.org/issues/19972 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-24 master c44d65427e) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- I think that the current situation, where the same directory (lets call it `Gem.default_dir`) is used for default/bundled gems as well as for user installed gems, is suboptimal. During the times, this has caused us quite some issue on Fedora. Historically, we redefined the `Gem.default_dir` to user home directory, to avoid the mixing of system gems and user installed gems. Unfortunately, with advent of default/bundled gems, we were facing issues that these gems were suddenly not listed, etc. I am realizing this issue in full once again since the "user install" RubyGems feature has landed [1]. I also think that we have arrived to this situation by evolution, not by design. Therefore my proposal is: Keep the `Gem.default_dir` for user `gem install`ed gems and lets install default and bundled gems into separate dedicated directories. Have separate `Gem.bundled_gems_dir` and `Gem.default_gems_dir` structures. Of course, if `Gem.default_dir == Gem.bundled_gems_dir == Gem.default_gems_dir`, we still can have the current layout. I have a simple POC here: https://github.com/ruby/ruby/pull/8761 BTW I have reported it here, because I think that RubyGems provides all it is needed. So it is not RubyGems ticket after all. However, I believe that RubyGems could benefit from this long term and some simplifications/cleanups would be possible. [1]: https://github.com/rubygems/rubygems/pull/5327 -- https://bugs.ruby-lang.org/

6 11

[ruby-core:125124] [Ruby Bug#21964] Fiber stack acquire can expand unnecessarily.
by ioquatix (Samuel Williams) 13 Jun '26

13 Jun '26

Issue #21964 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21964: Fiber stack acquire can expand unnecessarily. https://bugs.ruby-lang.org/issues/21964 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- In several common scenarios, the fiber stack allocator can choose to expand the fiber stack pool even when there are unreachable (effectively dead) fibers. For example, the following program will eventually crash if GC does not run in time: ```ruby loop do Fiber.new{Fiber.yield}.resume end ``` We have a loop that resumes a fiber, that fiber yields, and then becomes unreachable. Eventually, we will exhaust the OS vm map limit and fail with `FiberError`. However, at most only one fiber (stack) is needed to execute the above program, since the fiber immediately becomes unreachable. To fix this, we run GC before trying to expand the fiber stacks. In practice, fiber stacks are expanded on power of 2, up to 1024 fibers per allocation. So GC is only run in scenarios where we hit this limit. If GC is running normally, or fibers are terminating normally, we may never hit this code path. -- https://bugs.ruby-lang.org/

2 2

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

13 Jun '26

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

8 25

[ruby-core:125156] [Ruby Feature#21972] Add Date.birthday and Date.age to track Ruby's milestones
by jinroq (Jinroq SAITOH) 11 Jun '26

11 Jun '26

Issue #21972 has been reported by jinroq (Jinroq SAITOH). ---------------------------------------- Feature #21972: Add Date.birthday and Date.age to track Ruby's milestones https://bugs.ruby-lang.org/issues/21972 * Author: jinroq (Jinroq SAITOH) * Status: Open ---------------------------------------- Since its inception in 1993, Ruby has grown beyond a mere programming language to become a rich culture beloved by developers worldwide. However, the standard `date` library surprisingly lacks a formal interface to commemorate Ruby's own historical milestones. The fact that developers cannot programmatically reference Ruby’s heritage is a missed opportunity to foster affection and respect for the language's identity. To rectify this historical oversight, I propose adding the following methods to reference Ruby's key anniversaries and calculate the elapsed years. #### New Features * **`Date.birthday(version = nil)`** Returns the "birthday" of significant moments in Ruby's history. * `nil` (default): **1993-02-24** (The day the name "Ruby" was decided). * `0.95`: **1995-12-21** (The first public release date). * `1.0`: **1996-12-25** (The first stable release date). * **`Date.age(version = nil)`** Calculates the current age (in full years) based on today's date and the specified milestone. * `Date.age`: Years since the name "Ruby" was born. * `Date.age(0.95)`: Years since Ruby was first introduced to the public as OSS. * `Date.age(1.0)`: Years since Ruby began its journey as a stable language. #### Usage Example ```ruby # Check the "age" of each edition puts "Name age: #{Date.age}" # => 33 (as of 2026) puts "OSS age: #{Date.age(0.95)}" # => 30 puts "Stable: #{Date.age(1.0)}" # => 29 # Perform a special action on a specific anniversary if Date.today == Date.birthday(1.0) celebrate_stable_anniversary! end ``` #### Implementation and Testing The attached patch (`birthday_and_age.patch`) includes the implementation of these methods along with a rigorous test suite (`test/date/test_date_birthday.rb`). The tests cover argument dispatching, `ArgumentError` for invalid inputs, and edge cases for age calculation (e.g., boundaries before and after the actual birthday), ensuring production-level quality. Equipping Ruby with the intelligence to reflect upon its own origins is a vital step toward the next 30 or 40 years of its evolution. (Note: This proposal was submitted on a special day that encourages looking at our history with both deep respect and a touch of creative imagination, as is traditional for such a significant date in the calendar.) ---Files-------------------------------- birthday_and_age.patch (8.08 KB) -- https://bugs.ruby-lang.org/

5 8

[ruby-core:125157] [Ruby Feature#21973] Smile argument
by kinoppyd (Yasuhiro Kinoshita) 11 Jun '26

11 Jun '26

Issue #21973 has been reported by kinoppyd (Yasuhiro Kinoshita). ---------------------------------------- Feature #21973: Smile argument https://bugs.ruby-lang.org/issues/21973 * Author: kinoppyd (Yasuhiro Kinoshita) * Status: Open ---------------------------------------- Ruby makes us smile. So I want Ruby to smile too, and that is why I would like to propose this feature. The smile argument makes Ruby smile by allowing a method call to end its argument list with `:)`. smile_method(arg, :) This syntax implicitly supplies keyword arguments by matching the names of local variables in the current scope with the names of the method’s keyword parameters. For example, if a method has the following signature: ```ruby some_method(arg, smile:, hugging:) ``` then these two calls would be equivalent: ```ruby arg = "hello" smile = "smile" hugging = "hugging" some_method(arg, smile:, hugging:) ``` ```ruby arg = "hello" smile = "smile" hugging = "hugging" some_method(arg, :) ``` The motivation behind this feature is the assumption that names used in a method signature are often also used at the call site. For instance, if a library method defines keyword arguments like `(from:, to:)`, I expect that code using that method would often have local variables named `from` and `to` holding the actual values before passing them along. In real application development, when developers adopt a new library, they will usually look at the argument list of the method they want to call. If they intend to use that method as designed, it seems natural that they may also choose the same variable names as those in the method signature. This idea was inspired by Scala’s implicit parameters. It is not exactly the same feature, but as a lazy person, I find the idea of context-driven currying quite appealing. In any case, the real purpose is to make Ruby smile. Happy Ruby! And happy April Fools' Day! -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123958] [Ruby Feature#21720] Add a native Binary Heap / Priority Queue to Ruby's Standard Library (heapify, heappush, heappop)
by rahulk501 (Rahul Kumar) 11 Jun '26

11 Jun '26

Issue #21720 has been reported by rahulk501 (Rahul Kumar). ---------------------------------------- Feature #21720: Add a native Binary Heap / Priority Queue to Ruby's Standard Library (heapify, heappush, heappop) https://bugs.ruby-lang.org/issues/21720 * Author: rahulk501 (Rahul Kumar) * Status: Open ---------------------------------------- **Title:** Add a native Binary Heap / Priority Queue to Ruby's Standard Library (`heapify`, `heappush`, `heappop`) **Problem** Ruby currently lacks a native binary heap / priority queue data structure in the standard library. Users frequently reimplement heaps manually, or install third-party gems, simply to access common operations such as: * `heapify` * `heappush` * `heappop` * efficient priority queues Meanwhile, languages like Python provide a standard `heapq` module which is widely used in algorithms, AI, scheduling, job queues, pathfinding, graph traversal, and competitive programming. Because Ruby does not include a heap implementation, developers often write ad-hoc, buggy, or inconsistent versions of a heap. This leads to fragmentation and duplication. **Proposal** Introduce a lightweight `Heap` or `BinaryHeap` class to Ruby’s standard library with the following minimal API: ```ruby heap = Heap.new(array = []) heap.push(value) heap.pop # returns smallest (min-heap) heap.peek heap.size ``` Or a module-based functional API similar to Python’s `heapq`: ```ruby Heap.heapify(array) Heap.heappush(array, value) Heap.heappop(array) ``` Both designs are simple and allow backward-compatible extension. **Why include it in the standard library?** 1. Heaps are a *fundamental data structure*—used in sorting, algorithms, scheduling, and timers. 2. Many languages include them natively (Python, C++ via STL `priority_queue`, Java, Go, Rust `BinaryHeap`). 3. Adding it reduces unnecessary reimplementations in user codebases. 4. A small heap implementation adds little maintenance burden. 5. Existing Ruby solutions (gems like `algorithms`, `priority_queue`, custom code) are not universally available and often exceed what users need. **Reference Implementation (pure Ruby, minimal example)** ```ruby module Heap def self.heapify(arr) (arr.length / 2 - 1).downto(0) { |i| sift_down(arr, i) } arr end def self.heappush(arr, value) arr << value sift_up(arr, arr.length - 1) end def self.heappop(arr) return nil if arr.empty? arr[0], arr[-1] = arr[-1], arr[0] min = arr.pop sift_down(arr, 0) min end def self.sift_up(arr, i) while i > 0 p = (i - 1) / 2 break if arr[p] <= arr[i] arr[p], arr[i] = arr[i], arr[p] i = p end end def self.sift_down(arr, i) n = arr.length loop do left = 2 * i + 1 right = 2 * i + 2 smallest = i smallest = left if left < n && arr[left] < arr[smallest] smallest = right if right < n && arr[right] < arr[smallest] break if smallest == i arr[i], arr[smallest] = arr[smallest], arr[i] i = smallest end end private_class_method :sift_up, :sift_down end ``` **Optional C implementation** If accepted, I am willing to provide a minimal C version for performance parity with other stdlib containers. **Compatibility** No breaking changes expected. Naming avoids conflict with existing libraries. **Conclusion** Adding a tiny, well-defined heap structure would strengthen Ruby’s built-in algorithmic tools, reduce duplicated code across the ecosystem, and align Ruby with other mainstream languages. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:113430] [Ruby master Feature#19633] Allow passing block to `Kernel#autoload` as alternative to second `filename` argument
by shioyama (Chris Salzberg) 10 Jun '26

10 Jun '26

Issue #19633 has been reported by shioyama (Chris Salzberg). ---------------------------------------- Feature #19633: Allow passing block to `Kernel#autoload` as alternative to second `filename` argument https://bugs.ruby-lang.org/issues/19633 * Author: shioyama (Chris Salzberg) * Status: Open * Priority: Normal ---------------------------------------- `Kernel#autoload` takes two arguments, a symbol `module` representing the constant to be autoloaded, and a `filepath` to load the constant from (with `require`). Currently, Zeitwerk has to [monkeypatch `Kernel#require`](https://github.com/fxn/zeitwerk/blob/a7c4a983df0f4e4058f32c610dac1e8b99f687da/lib/zeitwerk/kernel.rb) to fetch the loader for the file being loaded, then run the original (aliased) `require`, then run autoload callbacks. In addition to the monkeypatch, this also requires a registry (`Zeitwerk::Registry`) to map file paths to loaders, to know which loader should be used for a given autoload-triggered `require`. In fact, Zeitwerk has to _assume_ that the monkey-patched `require` call came from an autoload trigger; there is no way to really be sure of the source. If Ruby allowed passing a block as an alternative to the explicit filepath, then I think this could be improved and would eliminate the need for a monkeypatch. So something like this: ```ruby autoload(:B) do require "lib/b" # trigger callback, etc end ``` I am implementing a gem called [Im](https://github.com/shioyama/im) which is a fork of Zeitwerk, and in the case of this gem, such a feature would be even more useful. Im implements autoloads on anonymous modules by registering an autoload and then "catching" the require and converting it into a `load`, passing the module as the second argument (see [here](https://github.com/shioyama/im/blob/44ce348639a1aae563a5be7a40602761e….) This is currently quite tricky because, again, it's hard to know _where_ a `require` came from. In addition to removing the monkeypatch (inherited from Zeitwerk), Im would further benefit from the block argument because then it could simply access the module via a closure, rather than pulling it from a registry: ```ruby mod.autoload(:Foo) do load "lib/foo.rb", mod end ``` I don't know how hard or easy this would be to implement, but if there is interest in this as a feature I'd be happy to look into implementing it. -- https://bugs.ruby-lang.org/

4 16