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

[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) 16 Dec '25

16 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

[ruby-core:124235] [Ruby Feature#6012] Proc#source_location also return the column
by vo.x (Vit Ondruch) 16 Dec '25

16 Dec '25

Issue #6012 has been updated by vo.x (Vit Ondruch). And RSpec were also adjusted to the new behavior AFAICT: https://github.com/rspec/rspec/pull/282/commits/1c20fa80772ca7a1ed0512056ce… ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115721 * 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

[ruby-core:124234] [Ruby Feature#6012] Proc#source_location also return the column
by vo.x (Vit Ondruch) 16 Dec '25

16 Dec '25

Issue #6012 has been updated by vo.x (Vit Ondruch). Just FTR, not sure how the revert is supposed to look like, but at least Pry was adjusted for the new behavior: https://github.com/pry/pry/pull/2357 It does not benefit from columns, but I suspect the revert would somehow influenced also the end of method location. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115720 * 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

[ruby-core:124232] [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). mame (Yusuke Endoh) wrote in #note-32: > I record the summary of the discussion regarding Matz's decision to revert this for now. The decision was based on a combination of several reasons: Thank you for documenting that. It feels to me like the decision was taken while we were in the middle of discussing https://bugs.ruby-lang.org/issues/21783, where we seem to now have reached an agreement, but the revert decision (and revert PR merged) was taken without any time for me to even reply there. > * Unclear use cases The fact many issues have been filed about this seems to show this is clearly a wanted feature. It has always been useful to find where a method/block is defined. https://rubygems.org/gems/method_source has 700 millions downloads, what other proof do we need? > * Difficulty in changing `Binding#source_location` (#6012#note-24, #21005#note-19) I wasn't aware of these, but I think this is much less needed than on {Proc,Method,UnboundMethod}. Unless I'm missing something, a Binding doesn't always have a properly-defined source location/definition, e.g. for `b = binding`. It has a start line if we consider that to be at the line of the `binding` call, but not really an end line/column. IOW it's not a "scope" unlike a method or block, and seems much less useful. > * Related issues: > * We may need to adjust Proc#source_location's position (#21784). > * We need to discuss column units (bytes vs characters) (#21783). I'm fixing both of these in https://github.com/ruby/ruby/pull/15580. Both issues seem to have rather clear agreements at this point. > * Timing: We can still revert without compatibility issues at this point. The feature has been implemented since 9th January, almost a year ago. It's not been in a proper release yet of course but it has been in multiple previews. I'm not sure if other people have tried it already, but I'm pretty confident a bunch of people are gonna be disappointed if this is removed last minute and it needs another year before it's in a Ruby release. Do we really want to encourage heuristics like https://bugs.ruby-lang.org/issues/20999#note-1 vs a proper a solution by providing the necessary information in `{Method,UnboundMethod,Proc}#source_location`? ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115718 * 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