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

[ruby-core:124305] [Ruby Bug#21793] function name conflict of "mutex_trylock" on Solaris
by ngoto (Naohisa Goto) 18 Dec '25

18 Dec '25

Issue #21793 has been reported by ngoto (Naohisa Goto). ---------------------------------------- Bug #21793: function name conflict of "mutex_trylock" on Solaris https://bugs.ruby-lang.org/issues/21793 * Author: ngoto (Naohisa Goto) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-18T07:47:43Z master 9f266ae674) +PRISM [sparc64-solaris2.10] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On Solaris, with GCC 7.5.0, failed to compile thread.c with "error: conflicting types for 'mutex_trylock'". On Solaris, the function name mutex_trylock(3C) is already used by the OS. https://docs.oracle.com/cd/E88353_01/html/E37843/mutex-trylock-3c.html It is a part of historical pre-POSIX mutex implementation, but it seems that it may still be internally used by the OS. Could you please change the name of "mutex_trylock" in thread_sync.c:238 to something else? The compile error message is below: ``` gcc -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wdeprecated-declarations -Wdiv-by-zero -Wduplicated-cond -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wwrite-strings -Wold-style-definition -Wimplicit-fallthrough=0 -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-packed-bitfield-compat -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wunused-variable -Wmisleading-indentation -Wundef -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -fPIE -I. -I.ext/include/sparc64-solaris2.10 -I.ext/include -I../ruby.devel/include -I../ruby.devel -I../ruby.devel/prism -I../ruby.devel/enc/unicode/17.0.0 -Dmodular_gc_dir="" -D_XOPEN_SOURCE=600 -I/usr/local/64/lib/libffi-3.0.10/include -I/usr/local/64/include -o thread.o -c ../ruby.devel/thread.c In file included from ../ruby.devel/thread.c:293:0: ../ruby.devel/thread_sync.c:238:1: error: conflicting types for 'mutex_trylock' mutex_trylock(rb_mutex_t *mutex, rb_thread_t *th, rb_serial_t ec_serial) ^~~~~~~~~~~~~ In file included from /usr/include/thread.h:24:0, from ../ruby.devel/thread_pthread.c:21, from ../ruby.devel/thread.c:278: /usr/include/synch.h:94:5: note: previous declaration of 'mutex_trylock' was here int mutex_trylock(mutex_t *); ^~~~~~~~~~~~~ ../ruby.devel/thread.c: In function 'rb_gc_set_stack_end': ../ruby.devel/thread.c:4809:44: warning: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas] COMPILER_WARNING_IGNORED(-Wdangling-pointer); ^ ../ruby.devel/thread.c: At top level: cc1: warning: unrecognized command line option '-Wno-self-assign' cc1: warning: unrecognized command line option '-Wno-parentheses-equality' cc1: warning: unrecognized command line option '-Wno-constant-logical-operand' cc1: warning: unrecognized command line option '-Wno-cast-function-type' make: *** [thread.o] Error 1 ``` The mutex_trylock function also exists in the Linux kernel, but is only available when the Linux kernel headers are included, so name conflicts may only occur in very specific, rare cases on Linux. https://manpages.debian.org/testing/linux-manual-4.8/mutex_trylock.9.en.html -- https://bugs.ruby-lang.org/

1 0

[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:124190] [Ruby Bug#21780] Change the default size of Enumerator.produce back to infinity
by zverok (Victor Shepelev) 17 Dec '25

17 Dec '25

Issue #21780 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #21780: Change the default size of Enumerator.produce back to infinity https://bugs.ruby-lang.org/issues/21780 * Author: zverok (Victor Shepelev) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In #21701 a new argument `size:` was introduced, and its default value is `nil` (unknown). While I support the new argument, I'd argue that the default should be `Float::INFINITY`. **Reasoning:** By _design_, `Enumerator.produce` is infinite (there is no internal condition to stop iteration), and the simplest, most straightforward usages of the method would produce _definitely infinite_ iterators, which the user than can limit with `take`, or `take_while` or similar methods. To produce the enumerator that will stop by itself requires explicit raising of `StopIteration`, which I expect to be a (slightly) advanced technique, and those who use it might be more inclined to provide additional arguments to clarify the semantics. While `Enumerator#size` is hardly frequently used now (other than in `#to_set`, which started the discussion), it might be in the future, and I believe it is better to stick with more user-friendly defaults. Now: ```ruby # very trivial enumerator, but if you want it to have "proper" size, you need # to not forget to use an elaborate argument and type additional 21 characters Enumerator.new(1, size: Float::INFINITY, &:succ) # already non-trivial enumerator, which is hardly frequently used, but the # current defaults correspond to its semantics: Enumerator.new(Date.today) { raise StopIteration if it.tuesday? && it.day.odd? it + 1 } ``` With my proposal: ```ruby # trivial, most widespread case: Enumerator.new(1, &:succ).size #=> Infinity # non-trivial case, with the enumerator designer clarifying their # intention that "we are sure it stops somewhere": Enumerator.new(Date.today, size: nil) { raise StopIteration if it.tuesday? && it.day.odd? it + 1 } ``` -- https://bugs.ruby-lang.org/

5 30

[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:124267] [Ruby Bug#21786] Net::HTTP::Response#read_body crashes on nil body when response_body_encoding is a String
by karinamendez132＠gmail.com (Karina Mendez) 17 Dec '25

17 Dec '25

Issue #21786 has been reported by karinamendez132(a)gmail.com (Karina Mendez). ---------------------------------------- Bug #21786: Net::HTTP::Response#read_body crashes on nil body when response_body_encoding is a String https://bugs.ruby-lang.org/issues/21786 * Author: karinamendez132(a)gmail.com (Karina Mendez) * Status: Open * ruby -v: ruby 3.2.0p0 (2022-12-25 revision a528908271) [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When response_body_encoding is set to a String value (e.g., 'UTF-8'), and the HTTP response body is nil due to network failures, read_body attempts to call force_encoding on nil at line 360, raising NoMethodError. The issue occurs because String values fall through to the else branch which calls detect_encoding(@body) without checking if @body is nil. Line 360 should verify @body is not nil before calling force_encoding. Category: lib Target version:current Reproducible script: require 'net/http' # Monkey patch to simulate nil body scenario class Net::HTTP::Response alias_method :original_reading_body, :reading_body def reading_body(sock, reqmethodallowbody) @socket = sock @body_exist = false # Force nil body begin yield self.body # Triggers the bug ensure @socket = nil end end end # Trigger the bug http = Net::HTTP.new('example.com', 443) http.use_ssl = true http.response_body_encoding = 'UTF-8' # String triggers else branch begin http.request(Net::HTTP::Get.new('/')) rescue NoMethodError => e puts "BUG: #{e.message}" puts "Location: #{e.backtrace.first}" end # Expected: Graceful handling # Actual: NoMethodError: undefined method `force_encoding' for nil:NilClass # from lib/net/http/response.rb:360:in `read_body' Suggested fix: In lib/net/http/response.rb line 360, change: @body.force_encoding(enc) if enc to: @body.force_encoding(enc) if enc && @body -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124121] [Ruby Bug#21772] ruby: YJIT has panicked StackOpnd(1) should be a heap object, but was ImmSymbol for VALUE(137647867319760)
by gearoiddc (Gearoid de Cleir) 16 Dec '25

16 Dec '25

Issue #21772 has been reported by gearoiddc (Gearoid de Cleir). ---------------------------------------- Bug #21772: ruby: YJIT has panicked StackOpnd(1) should be a heap object, but was ImmSymbol for VALUE(137647867319760) https://bugs.ruby-lang.org/issues/21772 * Author: gearoiddc (Gearoid de Cleir) * Status: Open * ruby -v: 3.4.7 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I'm getting a YJIT has panicked crash in my rails app locally when a part of my application rapidly uses a gem I have "auto_session_timeout". If I patch the gem by changing the symbol to a string the error goes away. ``` ruby module AutoSessionTimeout private def session_expired?(c) c.session[:auto_session_expires_at].<(Time.now) end end ``` to ``` ruby def session_expired?(c) c.session["auto_session_expires_at"].<(Time.now) end ``` I can consistently cause the crash but I can't find a way to reproduce the error in a snipped of code. But it looks like YJIT is keeping the key as a sybmol even though it was converted to a string. def [](key) load_for_read! key = key.to_s if key == "session_id" # <-- crash occurs here id&.public_id else @delegate[key] end end Didn't have the same issue on ruby 3.3 with YJIT. System Configuration Ruby Version: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +YJIT +PRISM [x86_64-linux] Environment: Ubuntu 22.04.5 LTS (x86_64) Backtrace & Logs ``` ruby: YJIT has panicked. More info to follow... thread '<unnamed>' panicked at ./yjit/src/codegen.rs:5018:9: StackOpnd(1) should be a heap object, but was ImmSymbol for VALUE(137647867319760) stack backtrace: 0: __rustc::rust_begin_unwind at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:697:5 1: core::panicking::panic_fmt at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/core/src/panicking.rs:75:14 2: yjit::codegen::jit_guard_known_klass at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/codegen.rs:5018:9 3: yjit::codegen::gen_equality_specialized at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/codegen.rs:3690:9 4: yjit::codegen::gen_opt_eq at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/codegen.rs:3753:29 5: yjit::codegen::gen_single_block at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/codegen.rs:1382:22 6: yjit::core::gen_block_series_body at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3088:23 7: yjit::core::gen_block_series at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3066:18 8: yjit::core::branch_stub_hit_body at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3604:17 9: yjit::core::branch_stub_hit::{{closure}}::{{closure}} at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3493:36 10: yjit::stats::with_compile_time at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/stats.rs:1084:15 11: yjit::core::branch_stub_hit::{{closure}} at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3493:13 12: std::panicking::catch_unwind::do_call at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:589:40 13: std::panicking::catch_unwind at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panicking.rs:552:19 14: std::panic::catch_unwind at /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/panic.rs:359:14 15: yjit::cruby::with_vm_lock at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/cruby.rs:688:21 16: yjit::core::branch_stub_hit at /home/travis/.rvm/src/ruby-3.4.7/yjit/src/core.rs:3492:9 17: <unknown> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. /home/gearoid/.rvm/gems/ruby-3.4.7@7.2.3/gems/actionpack-7.2.3/lib/action_dispatch/request/session.rb:118: [BUG] YJIT: panicked at ./yjit/src/codegen.rs:5018:9: StackOpnd(1) should be a heap object, but was ImmSymbol for VALUE(137647867319760) ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +YJIT +PRISM [x86_64-linux] ``` -- https://bugs.ruby-lang.org/

3 6

[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:124240] [Ruby Feature#6012] Proc#source_location also return the column
by Eregon (Benoit Daloze) 16 Dec '25

16 Dec '25

Issue #6012 has been updated by Eregon (Benoit Daloze). Right, I thought about that too but forgot to write it. Several gems have already adapted to this feature and their functionality and/or tests might rely on having the extra information, so it's definitely not great to remove this last minute. If https://github.com/ruby/prism/pull/3808 had been merged already we'd make the entire method unusable in Prism, which certainly sounds bad. I think we should do https://github.com/ruby/ruby/pull/15580 ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115726 * Author: rogerdpack (Roger Pack) * Status: Open * Assignee: nobu (Nobuyoshi Nakada) ---------------------------------------- As originally suggested in http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42418 Suggestion/feature request: have #source_location also return the beginning column where it was defined. ["test.rb", 8, 33] Thanks! -roger- -- https://bugs.ruby-lang.org/

1 0