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

[ruby-core:124553] [Ruby Misc#21839] DevMeeting-2026-02-12
by mame (Yusuke Endoh) 11 Feb '26

11 Feb '26

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

10 11

[ruby-core:124771] [Ruby Feature#15330] autoload_relative
by ioquatix (Samuel Williams) 11 Feb '26

11 Feb '26

Issue #15330 has been updated by ioquatix (Samuel Williams). Assignee changed from matz (Yukihiro Matsumoto) to ioquatix (Samuel Williams) https://github.com/ruby/ruby/pull/16148 ---------------------------------------- Feature #15330: autoload_relative https://bugs.ruby-lang.org/issues/15330#change-116380 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Assignee: ioquatix (Samuel Williams) ---------------------------------------- I'd like to propose a way to autoload a constant using a relative path. It could look like: ``` autoload_relative :MyConst, 'models/my_const' ``` My proposal raises two questions: 1) what's the future of `autoload`? I believe that `autoload` has been there for years, it is used successfully and has no real alternative. I looked at a sample of 430 top gems (took the 500 top ranked according to Libraries.io, removed those that I failed to process). The number of those gems that appear to use `autoload` at least once is 94 of those (22%). The number of lines in the code where `autoload` is called can be quite big. The top 5 are: vagrant: 235 yard: 206 ffaker: 155 aws-sdk: 152 rdoc: 92 This is a minimum bound, as some gems might be using loops, my processing would only detect the one place in the code with `autoload`. 2) are many autoladed paths relative? My preliminary numbers indicate that of the 94 gems using autoload, at least 75 are autoloading some relative files. That's a lower bound, as my algorithm is pretty crude and will only count the simplest cases as being relative. An example of gem my algorithm does not detect is `yard`, because the author wrote a small method to map the relative paths to global paths (code here: https://github.com/lsegal/yard/blob/master/lib/yard/autoload.rb#L3 ) Of those where my processing detects the relative requires, a vast majority are relative. The average is that 94% of autoloaded files are relative and would benefit from `require_relative` In summary: I am convinced that `autoload` should remain in Ruby indefinitely. `autoload_relative` would actually be more useful than `autoload`. Even if the future of `autoload` remains uncertain, I would recommend adding `autoload_relative`; if it is ever decided to actually remove `autoload`, removing `autoload_relative` would not really add to the (huge) burden of gem maintainers. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124631] [Ruby Bug#21851] Performance difference between / operator and fdiv
by mbrown1intel (Michael Brown) 11 Feb '26

11 Feb '26

Issue #21851 has been reported by mbrown1intel (Michael Brown). ---------------------------------------- Bug #21851: Performance difference between / operator and fdiv https://bugs.ruby-lang.org/issues/21851 * Author: mbrown1intel (Michael Brown) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Benchmarking fdiv against the / operator, it seems like fdiv is significantly slower. As far as I'm aware there's no functional difference between these two methods. I first ran this on 2.6, and then checked against 4.0 to make sure it hadn't been fixed in the meantime, and saw the same results. ``` ruby require 'benchmark' n = 500_000_000 c = nil Benchmark.bm do |benchmark| benchmark.report("to_f ") do n.times do |i| c = n / i.to_f end end benchmark.report("fdiv ") do n.times do |i| c = n.fdiv(i) end end end ``` ``` user system total real to_f 37.672000 0.110000 37.782000 ( 38.714876) fdiv 113.016000 0.265000 113.281000 (116.428442) ``` -- https://bugs.ruby-lang.org/

4 4

[ruby-core:124769] [Ruby Bug#21874] `PrettyPrint::SingleLine` is not API-compatible with `PrettyPrint`, breaking `PP` in some cases
by trinistr (Alexander Bulancov) 11 Feb '26

11 Feb '26

Issue #21874 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Bug #21874: `PrettyPrint::SingleLine` is not API-compatible with `PrettyPrint`, breaking `PP` in some cases https://bugs.ruby-lang.org/issues/21874 * Author: trinistr (Alexander Bulancov) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `PP` expects that a `#pretty_print` method can be used with both `PrettyPrint` and `PrettyPrint::SingleLine` interchangeably. This is used to [implement](https://github.com/ruby/pp/blob/b6f81ef83f9137c2300cb5eb96d44041… `#pretty_print_inspect`. As can be seen from `PP#pp`, a `NoMethodError` is expected when an object does not have `#pretty_print`, so it is [replaced](https://github.com/ruby/pp/blob/b6f81ef83f9137c2300cb5eb96d440419… with `Kernel#inspect`. As far as I can tell, `PrettyPrint::SingleLine` is intended to be compatible with regular `PrettyPrint`, considering it has no-op [methods and arguments](https://github.com/ruby/prettyprint/blob/c2ed83ca24f67a7ca6896d3…. However, it is missing some less-used methods: `#fill_breakable`, `#group_sub` and also `#current_group`, `#break_outmost_groups` and `attr_reader`s. I think only the first two are intended to be used by pretty-printed objects themselves, other methods are for use by output buffers a,d thus expected to be mssing. I'm personally interested in using `#fill_breakable`, because `#breakable` creates too many unneeded newlines in my case. Implementing `#pretty_print` for my [class](https://github.com/trinistr/vector_number/blob/6968e3ea534dc21e5bb0f… works well for IRB and `pp`: ```ruby irb(main):001> v = VectorNumber[1, "a", "z"] => (1 + 1⋅"a" + 1⋅"z") irb(main):002> pp v (1 + 1⋅"a" + 1⋅"z") => (1 + 1⋅"a" + 1⋅"z") ``` But `#pretty_print_inspect` inserts stringified instance when encountering `fill_breakable` due to `NoMethodError`: ```ruby irb(main):003> v.pretty_print_inspect => "(1#<VectorNumber:0x00007fcdd5bb10c0 ...>" ``` Implementing `#fill_breakable` and `#group_sub` for `PrettyPrint::SingleLine` is trivial, I can make a PR if needed. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124478] [Ruby Misc#21833] Switch default hash from SipHash13 to XXH3?
by samyron (Scott Myron) 10 Feb '26

10 Feb '26

Issue #21833 has been reported by samyron (Scott Myron). ---------------------------------------- Misc #21833: Switch default hash from SipHash13 to XXH3? https://bugs.ruby-lang.org/issues/21833 * Author: samyron (Scott Myron) * Status: Open ---------------------------------------- Has there been any consideration switching to some other hash implementation? I've searched through the issues and haven't found anything related to switching the default hash from SipHash13 to anything else. I created a [branch](https://github.com/ruby/ruby/compare/master...samyron:ruby:sm/xxh3) which switched `rb_memhash` from SipHash13 to [XXH3](https://github.com/Cyan4973/xxHash). I created a few simple benchmarks and ran them on my M1 Macbook Air. The results are very promising. ``` % cat ~/string_hash.yml prelude: | # Generate sets of short vs medium strings TINY_STRINGS = Array.new(100) { Array.new(3).map { (97 + rand(26)).chr }.join }.freeze SMALL_STRINGS = Array.new(100) { Array.new(8).map { (97 + rand(26)).chr }.join }.freeze MED_STRINGS = Array.new(100) { Array.new(20).map { (97 + rand(26)).chr }.join }.freeze LARGE_STRINGS = Array.new(100) { Array.new(200).map { (97 + rand(26)).chr }.join }.freeze HUGE_STRINGS = Array.new(100) { Array.new(65536).map { (97 + rand(26)).chr }.join }.freeze benchmark: tiny_strings: | TINY_STRINGS.each { |s| s.hash } small_strings: | SMALL_STRINGS.each { |s| s.hash } medium_strings: | MED_STRINGS.each { |s| s.hash } large_strings: | LARGE_STRINGS.each { |s| s.hash } huge_strings: | HUGE_STRINGS.each { |s| s.hash % benchmark-driver ~/string_hash.yml \ -e ruby-master::~/.rubies/ruby-master/bin/ruby \ -e ruby-xxhash::~/.rubies/ruby-xxhash/bin/ruby \ --output compare Warming up -------------------------------------- tiny_strings 262.513k i/s - 283.844k times in 1.081258s (3.81μs/i) small_strings 259.803k i/s - 280.445k times in 1.079454s (3.85μs/i) medium_strings 249.553k i/s - 267.531k times in 1.072041s (4.01μs/i) large_strings 116.426k i/s - 126.005k times in 1.082275s (8.59μs/i) huge_strings 498.481 i/s - 500.000 times in 1.003047s (2.01ms/i) Calculating ------------------------------------- ruby-master ruby-xxhash tiny_strings 264.070k 288.960k i/s - 787.538k times in 2.982305s 2.725421s small_strings 259.941k 286.229k i/s - 779.407k times in 2.998394s 2.723019s medium_strings 249.249k 283.952k i/s - 748.658k times in 3.003655s 2.636561s large_strings 116.572k 240.823k i/s - 349.278k times in 2.996244s 1.450351s huge_strings 500.164 5.296k i/s - 1.495k times in 2.989019s 0.282263s Comparison: tiny_strings ruby-xxhash: 288960.1 i/s ruby-master: 264070.2 i/s - 1.09x slower small_strings ruby-xxhash: 286229.0 i/s ruby-master: 259941.5 i/s - 1.10x slower medium_strings ruby-xxhash: 283952.5 i/s ruby-master: 249249.0 i/s - 1.14x slower large_strings ruby-xxhash: 240823.1 i/s ruby-master: 116571.9 i/s - 2.07x slower huge_strings ruby-xxhash: 5296.5 i/s ruby-master: 500.2 i/s - 10.59x slower ``` Running something a bit more real-world: ``` % cat ~/json_parse.yml prelude: | require 'json' activitypub_json_txt = File.read("/Users/scott/Development/json/benchmark/data/activitypub.json") twitter_json_txt = File.read("/Users/scott/Development/json/benchmark/data/twitter.json") citm_catalog_json_txt = File.read("/Users/scott/Development/json/benchmark/data/citm_catalog.json") ohai_json_txt = File.read("/Users/scott/Development/json/benchmark/data/ohai.json") benchmark: parse_activitypub_json: | JSON.parse(activitypub_json_txt) parse_twitter_json_txt: | JSON.parse(twitter_json_txt) parse_citm_catalog_json_txt: | JSON.parse(citm_catalog_json_txt) parse_ohai_json_txt: | JSON.parse(ohai_json_txt) % benchmark-driver ~/json_parse.yml \ -e ruby-master::~/.rubies/ruby-master/bin/ruby \ -e ruby-xxhash::~/.rubies/ruby-xxhash/bin/ruby \ --output compare Warming up -------------------------------------- parse_activitypub_json 10.969k i/s - 12.023k times in 1.096043s (91.16μs/i) parse_twitter_json_txt 1.169k i/s - 1.265k times in 1.082330s (855.60μs/i) parse_citm_catalog_json_txt 591.782 i/s - 600.000 times in 1.013887s (1.69ms/i) parse_ohai_json_txt 12.000k i/s - 12.782k times in 1.065168s (83.33μs/i) Calculating ------------------------------------- ruby-master ruby-xxhash parse_activitypub_json 10.986k 11.071k i/s - 32.908k times in 2.995440s 2.972542s parse_twitter_json_txt 1.162k 1.172k i/s - 3.506k times in 3.016331s 2.991486s parse_citm_catalog_json_txt 588.758 601.926 i/s - 1.775k times in 3.014820s 2.948868s parse_ohai_json_txt 10.747k 12.400k i/s - 35.999k times in 3.349753s 2.903138s Comparison: parse_activitypub_json ruby-xxhash: 11070.7 i/s ruby-master: 10986.0 i/s - 1.01x slower parse_twitter_json_txt ruby-xxhash: 1172.0 i/s ruby-master: 1162.3 i/s - 1.01x slower parse_citm_catalog_json_txt ruby-xxhash: 601.9 i/s ruby-master: 588.8 i/s - 1.02x slower parse_ohai_json_txt ruby-xxhash: 12400.0 i/s ruby-master: 10746.8 i/s - 1.15x slower ``` Admittedly, I'm not a hash expert nor a cryptographer. There doesn't seem to be any known vulnerabilities with XXH3 that I have found. -- https://bugs.ruby-lang.org/

4 9

[ruby-core:124688] [Ruby Bug#21865] Crash on signal raise
by dodecadaniel (Daniel Colson) 10 Feb '26

10 Feb '26

Issue #21865 has been reported by dodecadaniel (Daniel Colson). ---------------------------------------- Bug #21865: Crash on signal raise https://bugs.ruby-lang.org/issues/21865 * Author: dodecadaniel (Daniel Colson) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- This crashes on Ruby 4.0 ``` sh $ ruby -e 'loop { File.open("./test.rb", kwarg: true) {} }'& [1] 93542 $ kill -TERM 93542 [BUG] Segmentation fault at 0x000000000000001f ``` Note the `0x1f`, which is Ruby 15, which is `Signal.list["TERM"])`. While preparing the exception we pass argc=2, with argv containing the signal class and the fixnum for the TERM. https://github.com/ruby/ruby/blob/86dba8cfaeabb3b86df921da24b3243b9ce4ab2a/… That eventually gets passed through to https://github.com/ruby/ruby/blob/86dba8cfaeabb3b86df921da24b3243b9ce4ab2a/…, where we set the signal fixnum as `last` and treat it like a hash. But 0x1f is a fixnum, not a hash, so that crashes. `rb_scan_args_keyword_p` returns true in this case even though `last` is not a hash because kw_flag is `RB_SCAN_ARGS_PASS_CALLED_KEYWORDS` (which I think causes it to look at the last frame to see if keywords were passed, rather than checking whether `last` is a hash. I don't think we push any frames in this case, so it's looking at whatever the last frame before the signal happened to be). Should we still check that it's a hash regardless? I believe the bug was introduced in https://github.com/ruby/ruby/commit/64f508ade8c8535b7d3ecdd217886aa52fddd43c. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:124731] [Ruby Misc#21872] `-S` with directory separator
by nobu (Nobuyoshi Nakada) 10 Feb '26

10 Feb '26

Issue #21872 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Misc #21872: `-S` with directory separator https://bugs.ruby-lang.org/issues/21872 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- Ruby’s `-S` option searches the script from `$RUBYPATH` and `$PATH` always: ```console $ mkdir -p a/test $ echo 'p $0' > a/test/t.rb $ chmod +x a/test/t.rb $ PATH=$PWD/a:$PATH ruby -S test/t.rb ``` However, I don't think this action is intentional, because Perl’s `-S` doesn't search `$PATH` as stated at https://perldoc.perl.org/perlrun#-S: > makes Perl use the "PATH" environment variable to search for the program **unless the name of the program contains path separators**. ```console $ mkdir -p a/test $ echo 'print $0, "\n"' > a/test/t.pl $ chmod +x a/test/t.pl $ PATH=$PWD/a:$PATH perl -S test/t.pl Can't open perl script "test/t.pl": No such file or directory ``` This is same in `sh`: ```console $ echo 'echo $0' > a/test/t.sh $ chmod +x a/test/t.sh $ PATH=$PWD/a:$PATH sh -c test/t.sh sh: test/t.sh: No such file or directory ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:124755] [Ruby Feature#6478] BasicObject#__class__
by byroot (Jean Boussier) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by byroot (Jean Boussier). > So my take on this is KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj) is good enough, Yeah me too, I was just mentioning the existence of `__id__` etc. But I agree that when code need to work with any arbitrary object, like e.g. `zeitwerk` or `tapioca`, then `UnboundMethod` is the safe way. That being said it's unfortunate that it doesn't perform better on CRuby. I just had a look and It does allocate a `Class` (at least for module methods) and a `method_entry_t`, which is quite heavy for a call like `#class`. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116361 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124278] [Ruby Feature#21788] Promote Thread::Monitor to a core class
by byroot (Jean Boussier) 09 Feb '26

09 Feb '26

Issue #21788 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21788: Promote Thread::Monitor to a core class https://bugs.ruby-lang.org/issues/21788 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- `Monitor` is about as useful as `Mutex` and yet one is a core class and the other is a "stdlib" extension. I propose to promote `Thread::Monitor` as a core class convenience. ### The rest of `monitor.rb` The `monitor` stdlib also contains `MonitorMixin`, but I think this part can remain in `lib/monitor.rb` (or even be moved to `lib/monitor_mixin.rb`. One more questionable part is `Monitor#new_cond`, as it returns a `::MonitorMixin::ConditionVariable` so it would also need to remain in the stdlib. ### Performance benefit By being a core class, Monitor can also be implemented more efficiently, as it is no longer constrained to the public C API. On my branch, monitor is approximately 15% faster (but there might be some more optimizations to be found). `master`: ``` ruby 4.0.0dev (2025-12-17T07:21:34Z core-monitor 32815a1bc4) +YJIT +PRISM [arm64-darwin25] Warming up -------------------------------------- Mutex 1.975M i/100ms Monitor 1.936M i/100ms Calculating ------------------------------------- Mutex 25.213M (± 0.4%) i/s (39.66 ns/i) - 126.407M in 5.013728s Monitor 24.099M (± 0.1%) i/s (41.50 ns/i) - 121.992M in 5.062092s ``` core monitor: ``` ruby 4.0.0dev (2025-12-17T07:16:32Z master 54d3945ee5) +YJIT +PRISM [arm64-darwin25] Warming up -------------------------------------- Mutex 1.952M i/100ms Monitor 1.775M i/100ms Calculating ------------------------------------- Mutex 25.102M (± 0.4%) i/s (39.84 ns/i) - 126.884M in 5.054731s Monitor 21.189M (± 0.1%) i/s (47.19 ns/i) - 106.485M in 5.025493s ``` Proposed implementation: https://github.com/ruby/ruby/pull/15538 -- https://bugs.ruby-lang.org/

4 8

[ruby-core:124552] [Ruby Bug#21838] Rails seeding degradation (20% slowdown) related to Revision 079ef92b "Implement global allocatable slots and empty pages" (from Sep 5 2024)
by bluz71 (Dennis B) 09 Feb '26

09 Feb '26

Issue #21838 has been reported by bluz71 (Dennis B). ---------------------------------------- Bug #21838: Rails seeding degradation (20% slowdown) related to Revision 079ef92b "Implement global allocatable slots and empty pages" (from Sep 5 2024) https://bugs.ruby-lang.org/issues/21838 * Author: bluz71 (Dennis B) * Status: Open * ruby -v: ruby 3.4.0dev (2024-09-09T14:15:21Z v3_4_0_preview2~545 079ef92b5e) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I noticed a performance degradation with Ruby 3.4 when seeding my Rails application, which does image derivation via the Shrine Gem and `libvips` image library. I skipped Ruby 3.4 hoping that 4.0 would magically solve my performance issue. Alas not. My degradation when doing `rails db:reset` (aka database seeding) was about 20% as compared with Ruby 3.3. The last couple of days I looked at this issue more closely and with the help of `git bisect` I believe this commit: https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/07… is the cause of my regression. That commit implements global allocatable slots and empty pages. The revision before is fast when seeding my Rails application. This revision however slows down my Rails seeding by about 20%, from 30 seconds to 40 seconds consistently. I created a minimal Rails application as the reproducible test case: https://github.com/bluz71/rails_app_ruby_slowdown Steps to reproduce: 1. `git clone https://github.com/bluz71/rails_app_ruby_slowdown` 2. `cd rails_app_ruby_slowdown` 3. `bundle config set force_ruby_platform true` 4. `bundle install` 5. `bundle exec rails db:create` 6. `RUBY_YJIT_ENABLE=0 time bundle exec rails db:reset` Note, `libvips` needs to be installed at the system level, for example `sudo apt install libvips`, libvips is the image processing library used by Shrine which in turn is used in this Rails application when seeding. Use Ruby 3.3 and 3.4 to compare, or use Revision de7ac11a (https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/de…) and Revision 079ef92b (https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/07…) to compare. I hope this is reproducible, if so, I also hope this performance loss can be minimised in future. Best regards. -- https://bugs.ruby-lang.org/

5 6