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

[ruby-core:121234] [Ruby master Bug#21168] Prism doesn't require argument parentheses (in some cases) when a block is present but parse.y does
by Earlopain (Earlopain _) 28 Dec '25

28 Dec '25

Issue #21168 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21168: Prism doesn't require argument parentheses (in some cases) when a block is present but parse.y does https://bugs.ruby-lang.org/issues/21168 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- It's a bit more than that but explaining it in full would be a bit much. Instead, see this: ```rb foo( bar baz do end ) ``` ```sh $ ruby -c --parser=prism test.rb Syntax OK $ ruby -c --parser=parse.y test.rb ruby: test.rb:2: syntax error, unexpected 'do' for block, expecting ')' (SyntaxError) bar baz do ^~ ``` OTOH, this is consistently rejected: ```rb [ foo bar do end, ] # And also foo || bar baz do end ``` -- https://bugs.ruby-lang.org/

7 9

[ruby-core:121642] [Ruby Bug#21266] YJIT GC safety crash with proc objects as block argument
by alanwu (Alan Wu) 19 Dec '25

19 Dec '25

Issue #21266 has been reported by alanwu (Alan Wu). ---------------------------------------- Bug #21266: YJIT GC safety crash with proc objects as block argument https://bugs.ruby-lang.org/issues/21266 * Author: alanwu (Alan Wu) * Status: Open * Assignee: yjit * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- ```ruby # Run with --yjit-call-threshold=1 def foo(args) = bar(*args, &proc { _1 }) def bar(_, _, _, _, *rest) = yield rest GC.stress = true foo([1,2,3,4]) foo([1,2,3,4]) ``` The proc in these calls get collected on the yield to the GC to allocate the rest parameter arary. ``` ../vm_core.h:1668: Assertion Failed: vm_block_handler_type:rb_obj_is_proc(block_handler) ``` Or in release builds: ``` ../test.rb:1: [BUG] Segmentation fault at 0x0000000000000020 ruby 3.3.6 (2024-11-05 revision 75015d4c1f) +YJIT [arm64-darwin24] -- C level backtrace information ------------------------------------------- /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_bugreport+0xb4c) [0x104595590] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_bug_for_fatal_signal+0x100) [0x1043d6120] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(sig_do_nothing+0x0) [0x1044fc4b0] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x187572de4] /Users/alan/.rubies/ruby-3.3.6/bin/ruby(rb_vm_invokeblock+0x144) [0x10456b004] ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123845] [Ruby Bug#21696] Performance degradation for long running processes in Ruby 4.0.0-preview2
by easydwh (Ivo Herweijer) 19 Dec '25

19 Dec '25

Issue #21696 has been reported by easydwh (Ivo Herweijer). ---------------------------------------- Bug #21696: Performance degradation for long running processes in Ruby 4.0.0-preview2 https://bugs.ruby-lang.org/issues/21696 * Author: easydwh (Ivo Herweijer) * Status: Open * ruby -v: ruby 4.0.0preview2 (2025-11-17 master 4fa6e9938c) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When running my RubyMeasureResponsetime tool (https://github.com/easydatawarehousing/ruby_measure_responsetime) on Ruby 4.0.0-preview2, a slow but steady performance degradation is measurable. Both the Rails and the Roda based test applications show this. And both with and without yjit. The Rails application when using yjit also seems to have increasing memory usage over time. Running the same tests on Ruby 3.4.7 shows stable performance and memory usage. I have included some plots showing this behavior. ---Files-------------------------------- rails_devise_2_ruby-4.0.0.jpg (965 KB) rodauth_2_ruby-4.0.0 YJIT.jpg (973 KB) rodauth_2_ruby-4.0.0.jpg (1.02 MB) rails_devise_2_ruby-4.0.0 YJIT.jpg (917 KB) rails_devise_0_memory.png (31.2 KB) -- https://bugs.ruby-lang.org/

3 5

[ruby-core:118957] [Ruby master Bug#20699] On Windows, the `__dir__` keyword is garbled in paths containing Japanese characters, and `require_relative` fails as well
by flatland001 (Hayato Arai) 18 Dec '25

18 Dec '25

Issue #20699 has been reported by flatland001 (Hayato Arai). ---------------------------------------- Bug #20699: On Windows, the `__dir__` keyword is garbled in paths containing Japanese characters, and `require_relative` fails as well https://bugs.ruby-lang.org/issues/20699 * Author: flatland001 (Hayato Arai) * Status: Open * ruby -v: ruby 3.3.4 (2024-07-09 revision be1089c8ec) [x64-mingw-ucrt] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In paths containing Japanese characters, such as: C:\テスト_test\test.rb Code: ``` ruby # this code -> C:\テスト_test\test.rb # external file -> C:\テスト_test\lib\foo.rb p __dir__ p __dir__.encoding p File.dirname(File.expand_path(__FILE__)) p File.dirname(File.expand_path(__FILE__)).encoding print "__dir__ == File.dirname(File.expand_path(__FILE__)): " p __dir__ == File.dirname(File.expand_path(__FILE__)) begin require_relative "lib/foo" puts "foo.rb loaded" rescue LoadError puts "LoadError: #{$!}" end ``` Results: ``` "C:/?e?X?g_test" #<Encoding:Windows-31J> "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> __dir__ == File.dirname(File.expand_path(__FILE__)): false LoadError: cannot load such file -- C:/?e?X?g_test/lib/foo ``` However, in ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x64-mingw-ucrt], the same code produces the following expected results: ``` "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> "C:/\x{8365}\x{8358}\x{8367}_test" #<Encoding:Windows-31J> __dir__ == File.dirname(File.expand_path(__FILE__)): true foo.rb loaded ``` Is this behavior expected, or could this be a bug in the Ruby interpreter on Windows? If this is my misunderstanding or a known issue, I apologize. Thank you for your consideration. Environment Information: - OS: Windows 11 Pro 23H2 (OS build 22631.4037) - Installed via: RubyInstaller - Shell: Command Prompt - File System: NTFS - System Locale: Japanese (Japan), Language: Japanese -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120743] [Ruby master Bug#21049] Reconsider handling of the numbered parameters and "it" parameter in `Binding#local_variables`
by mame (Yusuke Endoh) 18 Dec '25

18 Dec '25

Issue #21049 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #21049: Reconsider handling of the numbered parameters and "it" parameter in `Binding#local_variables` https://bugs.ruby-lang.org/issues/21049 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: matz (Yukihiro Matsumoto) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Currently, `Binding#local_variable*` APIs wrongly handles the numbered parameters. ```ruby # Binding#local_variables includes numbered parameters that should not be visible "foo".tap do _1 "bar".tap do p binding.local_variables #=> expected: [], actual: [:_1] end end # Binding#local_variable_get can read numbered parameters that should not be readable "foo".tap do _1 "bar".tap do p binding.local_variable_get(:_1) #=> expected: NameError, actual: "foo" end end # Binding#local_variable_set can update numbered parameter "foo".tap do p _1 #=> "foo" binding.local_variable_set(:_1, "bar") # expected: NameError, actual: updates _1 p _1 #=> "bar" end ``` My proposal is to stop handling numbered parameters and "it" parameter in `Binding#local_variable*` APIs. ```ruby "foo".tap do _1 binding.local_variables #=> proposed: [] binding.local_variable_get(:_1) #=> proposed: NameError end ``` Here is a proof-of-concept patch. https://github.com/ruby/ruby/pull/12601 It would be theoretically possible to fix `Binding#local_variable*` APIs to handle numbered parameters while maintaining compatibility as much as possible. However, I think the implicit “it” parameter introduced in Ruby 3.4 poses a spec-level problem. This is because there is no way to distinguish between the implicit “it” parameter and a true local variable named "it". Also, I don't think numbered parameters are local variables, so I feel uncomfortable handling them by `Binding#local_variable*` APIs. If it is absolutely necessary to access numbered parameters or "it" parameter via binding, it would be good to introduce dedicated APIs for the purpose, as: * Binding#numbered_parameters #=> [:_1, :_2, :_3, ...] * Binding#numbered_parameter_get(:_1) #=> obj * Binding#numbered_parameter_defined?(:_1) #=> true or false * Binding#it_get #=> obj * Binding#it_defined? #=> true or false Personally, however, I do not see the need for these APIs currently. I implemented them as proof-of-concept in PR, but I am okay that they are not introduced. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:121252] [Ruby master Bug#21174] Range#max called with an argument on a beginless Integer Range raises RangeError
by andrykonchin (Andrew Konchin) 17 Dec '25

17 Dec '25

Issue #21174 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21174: Range#max called with an argument on a beginless Integer Range raises RangeError https://bugs.ruby-lang.org/issues/21174 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.4.2 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- It seems surprising but instead of returning last `n` Integers `Range#max(n)` raises `RangeError`: ```ruby (nil..10).max(2) # => (irb):3:in 'Range#max': cannot get the maximum of beginless range with custom comparison method (RangeError) ``` I would expect `[9, 10]` to be returned. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:120250] [Ruby master Feature#20953] Array#fetch_values vs #values_at protocols
by zverok (Victor Shepelev) 17 Dec '25

17 Dec '25

Issue #20953 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #20953: Array#fetch_values vs #values_at protocols https://bugs.ruby-lang.org/issues/20953 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- I believe that the user might expect `#fetch_values` to be a stricter version of `#values_at`, confirming to the same protocol for arguments. But the current implementation for `#fetch_values` is simpler: ```ruby [1, 2, 3, 4, 5].values_at(0, 3..4) #=> [1, 4, 5] [1, 2, 3, 4, 5].fetch_values(0, 3..4) # TypeError: in 'Array#fetch': no implicit conversion of Range into Integer ``` I believe aligning the implementations would lessen confusion (even if it makes `#fetch_values` implementation somewhat less trivial). The practical example of usefulness: ```ruby HEADERS = %w[Name Department] def table_headers(rows) HEADERS.fetch_values(...rows.map(&:size).max) { '<unknown'> } # Or, alternatively: # HEADERS.fetch_values(...rows.map(&:size).max) { raise ArgumentError, "No header defined for column #{it + 1}" } end table_headers([ ['John'], ['Jane'], ]) #=> ["Name"] table_headers([ ['John'], ['Jane', 'Engineering'], ]) #=> ["Name", "Department"] table_headers([ ['John', 'Accounting', 'Feb 24'], ['Jane', 'Engineering'], ]) #=> ["Name", "Department", "<unknown>"] # or ArgumentError No header defined for column 3 ``` (Obviously, we can use `fetch_values(*(0...max_row_size))` as an argument, but it feels like an unjustified extra work when `values_at` already can do this.) -- https://bugs.ruby-lang.org/

3 12

[ruby-core:122558] [Ruby Bug#21446] StackOverflow when changing visibility in reopened refinement
by luke-gru (Luke Gruber) 16 Dec '25

16 Dec '25

Issue #21446 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #21446: StackOverflow when changing visibility in reopened refinement https://bugs.ruby-lang.org/issues/21446 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.5.0 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby class A def a :a end end class B < A end module R refine B do private :a end end module R refine B do public :a end end using R B.new.a # StackOverflow ``` I would expect it to change the visibility, not to overflow the stack. -- https://bugs.ruby-lang.org/

4 3

[ruby-core:123576] [Ruby Bug#21654] Set#new calls extra methods compared to previous versions
by tenderlovemaking (Aaron Patterson) 16 Dec '25

16 Dec '25

Issue #21654 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21654: Set#new calls extra methods compared to previous versions https://bugs.ruby-lang.org/issues/21654 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.5.0dev (2025-10-24T15:50:47Z master a9f24aaccb) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I'm trying to test Ruby 3.5.0 with our Rails application and we've found that `Set.new` is now causing extra database queries to happen. The changes in d4020dd5faf call "size" on enumerable objects that are passed to the `new` method, and this causes extra "COUNT" queries to happen with ActiveRecord associations. For example: ```ruby Set.new(some_activerecord_association) ``` Previously, the above code would only do one query by iterating over the association. Now it issues two queries, a count query, and then the normal query for results. Since d4020dd5faf is dealing with endless ranges, I would like to narrow the scope from all Enumerable objects to just Ranges. Unfortunately, I noticed we have a test like this: ```ruby assert_raise(ArgumentError) { Set.new(1.upto(Float::INFINITY)) } ``` I'm not sure how we can handle such a case without testing `size`. -- https://bugs.ruby-lang.org/

8 19

[ruby-core:123754] [Ruby Feature#21678] Enumerable#rfind
by kddnewton (Kevin Newton) 15 Dec '25

15 Dec '25

Issue #21678 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21678: Enumerable#rfind https://bugs.ruby-lang.org/issues/21678 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I'd like to introduce `rfind` to enumerable, which would effectively be the same as `reverse_each.find`. I've found myself using this a surprising number of times, and have been surprised at its omission. That means either falling back to `reverse_each` or `rindex`. For context, here are a couple of examples of this in the wild: * [pry](https://github.com/pry/pry/blob/80816f596774d00afdc81a555724b0819bf267… * [bundler](https://github.com/ruby/rubygems/blob/e4fd4ee3fad005fce1dbcbeffd47… * [textbringer](https://github.com/shugo/textbringer/blob/738d318558045efc9d97… -- https://bugs.ruby-lang.org/

5 7