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

[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:122355] [Ruby Feature#21389] Simplify Set#inspect output
by jeremyevans0 (Jeremy Evans) 14 Dec '25

14 Dec '25

Issue #21389 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21389: Simplify Set#inspect output https://bugs.ruby-lang.org/issues/21389 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- As Set is now a core collection class, it should have special inspect output. Ideally, inspect output should be suitable to eval, similar to array and hash (assuming the elements are also suitable to eval): ```ruby set = Set[1, 2, 3] eval(set.inspect) == set # should be true ``` The simplest way to do this is to use the Set[] syntax: ```ruby Set[1, 2, 3].inspect # => "Set[1, 2, 3]" ``` I've submitted a pull request that implements this: https://github.com/ruby/ruby/pull/13488 The pull request deliberately does not use any subclass name in the output, similar to array and hash. I think it is more important that users know they are dealing with a set than which subclass: ```ruby Class.new(Set)[] # PR does: Set[] # not: #<Class:0x00000c21c78699e0>[] ``` However, it's easy to change the PR to use a subclass name if that is desired. -- https://bugs.ruby-lang.org/

4 5

[ruby-core:119380] [Ruby master Misc#20774] Remove remaining locale dependent code from Windows port
by larskanis (Lars Kanis) 12 Dec '25

12 Dec '25

Issue #20774 has been reported by larskanis (Lars Kanis). ---------------------------------------- Misc #20774: Remove remaining locale dependent code from Windows port https://bugs.ruby-lang.org/issues/20774 * Author: larskanis (Lars Kanis) * Status: Open ---------------------------------------- The external_encoding of files, file names and ENV on Windows were changed from locale codepage to UTF-8 in ruby-3.0. But there are still several remaining points where locale encoding is used although there is no need to do so. The Windows port is already fully UTF-16/UTF-8 based and locale encoding is only used for historical and not for technical reasons. My proposal is to remove (most of) the locale dependent conversions from the ruby code for Windows. Before I open pull requests in this regard, I would like to confirm this direction with the ruby core team. Let me show what I mean: ``` # täst-locale-enc.rb def pr(*strs) strs.each do |str| p [str, IO===str ? str.external_encoding&.name : str.encoding.name] end end if $0==__FILE__ pr STDIN # => [#<IO:<STDIN>>, "CP850"] pr $0 # => ["ruby/t\x84st-locale-enc.rb", "CP850"] pr __FILE__ # => ["ruby/t\x84st-locale-enc.rb", "CP850"] pr __dir__ # => ["C:/Users/kanis/ruby", "CP850"] pr 'ä' # => ["ä", "UTF-8"] pr '€' # => ["€", "UTF-8"] pr $:.first # => ["C:/Users/kanis/t\xE2\x82\xACst", "ASCII-8BIT"] pr $:.last # => ["C:/Ruby33-x64/lib/ruby/3.3.0/x64-mingw-ucrt", "CP850"] require "win32/registry" pr Win32::Registry::HKEY_CURRENT_USER.open("Environment")['TMP'] # => ["C:\\Users\\kanis\\AppData\\Local\\Temp", "UTF-8"] pr Win32::Registry::HKEY_CURRENT_USER.open("\\").each_key{ break _1 } # => ["AppEvents", "CP850"] end # execute with: ruby -It€st ruby\täst-locale-enc.rb ``` I wrote the results on `ruby-3.3 x64-mingw-ucrt` right into the code. The situation is even worse when called with `-e` script: ``` $ ruby -It€st -r .\ruby\täst-locale-enc.rb -e "pr STDIN, $0, __FILE__, __dir__, 'ä', '€', $:.first, $:.last" [#<IO:<STDIN>>, "CP850"] ["-e", "CP850"] ["-e", "UTF-8"] [".", "US-ASCII"] ["\x84", "CP850"] ["?", "CP850"] ["C:/Users/kanis/t\xE2\x82\xACst", "ASCII-8BIT"] ["C:/Ruby33-x64/lib/ruby/3.3.0/x64-mingw-ucrt", "CP850"] ``` There are also some inconsistencies like that it's possible to `require` script names with characters outside of the codepage, but it fails to execute a script directly or by using `require_relative` : ``` $ ruby -r .\t€st-locale-enc.rb -e "pr STDIN" [#<IO:<STDIN>>, "CP850"] $ ruby .\t€st-locale-enc.rb ruby: Invalid argument -- ./t?st-locale-enc.rb (LoadError) ``` Maybe there are more places which are working with locale codepage - these are only the few that I remember from memory. I would like to change all the above results to be UTF-8 encoded, like it is the case on Ubuntu. Compatibility ------------- Changing the encoding of returned strings is of course an API change. IMHO it is still something we should change in a minor release of ruby. The reason is that I don't remember about only a single issue cased by the change to UTF-8 in ruby-3.0 in the company I work for. To the contrary many issues are caused by using locale codepage where some non-ASCII characters work and other characters don't. Most issue with ruby-3.0 were cased by the keyword argument changes. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:120279] [Ruby master Feature#20959] Add a way to get codepage of console.
by YO4 (Yoshinao Muramatsu) 12 Dec '25

12 Dec '25

Issue #20959 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Feature #20959: Add a way to get codepage of console. https://bugs.ruby-lang.org/issues/20959 * Author: YO4 (Yoshinao Muramatsu) * Status: Open ---------------------------------------- # Abstract Add a way to retrieve code pages of console. On Windows, Encoding.find("locale") returns the console codepage. To prepare for future changes, specify ```console``` instead of ```locale``` to get the encoding when a console code page is needed. # Background On Windows, Encoding.find("locale") returns the console codepage. This is different from locale in other environments. Also the name and content do not seem to match. In the future, if we change the locale_encoding of the Windows port to the locale codepage of the C runtime library, we need to get the encoding for the console. Strings received via pipe from cmd.exe or powershell are encoded in the console codepage. This would be necessary when communicating with other programs via pipes. # Proposal Make Encoding.find("console") return the encoding that represents the console codepage. # Background(continued) Since Windows 10, UTF-8 support seems to be enhanced in the commandline environment. * build 17134 ucrt supports UTF-8 locale codepage ```setlocale(LC_CTYPE, ".utf8")``` Windows support UTF-8 ANSI Codepage(experimental) ```Beta: Use Unicode UTF-8 for worldwide language support``` * build 18362 support ```Set a process code page to UTF-8``` via manifest. * build 19041 Time zone name holds in wchar_t internaly, so proper tzname can be obtained regardless of the Windows language setting. This should not be all. Through these, I feel that the Microsoft team recommends the use of utf-8. It also seems that Microsoft, which has previously depricated the ANSI version of the API, is treating it as a valid alternative to use in UTF-8. If it becomes widespread on Windows for libraries to respect the C runtime library locale, ruby would do better to follow it. Of course, it is good to be able to get the encoding of the console by specifying a console. # Future plan By reducing differences from other platforms, bugs and extra code are hoped to be reduced. * Do ```setlocale(LC_CTYPE, ".utf8");``` in main.c (or refer LC_* environment variables). * ```Encoding.find("locale")``` returns C runtime library locale. Since strings obtained from the Windows system have a Unicode code range, the API to obtain fixed UTF-8 encoding remains unchanged. # Discussion The code page we can get from Windows also has ACP and OEMCP, but are these necessary? Is it reasonable to get locale_encoding if Encoding.find("console") is called on other platforms? -- https://bugs.ruby-lang.org/

3 4

[ruby-core:117003] [Ruby master Bug#20314] Simultaneous Timeout expires may raise an exception after the block
by mame (Yusuke Endoh) 11 Dec '25

11 Dec '25

Issue #20314 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20314: Simultaneous Timeout expires may raise an exception after the block https://bugs.ruby-lang.org/issues/20314 * Author: mame (Yusuke Endoh) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Launchable reports `TestTimeout#test_nested_timeout` as a flaky test, and I reproduced it as follows. ```ruby require "timeout" class A < Exception end class B < Exception end begin Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do nil while true end end rescue A, B p $! #=> #<A: execution expired> # Exception B is raised after the above call returns #=> test.rb:16:in `p': execution expired (B) p :end # not reach end ``` This is because the timer thread performs two consecutive `Thread#raise` to the target thread. I have discussed this with @ko1 and have come up with three solutions. ### Solution 1 When multiple nested Timeouts expire simultaneously, raise an exception for the outer-most Timeout and let the inner Timeouts expire without throwing an exception. In the above example, it would only raise A. The problem with this approach is that if you are rescuing A in the inner block, it may never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue A sleep # The exception A is caught. The inner Timeout is already expired, so the code (may) never end. end end end ``` Note that, if A and B did not occur at the same time, it would raise B. This is a race condition. ### Solution 2 When multiple nested Timeouts expire simultaneously, raise an exception for the inner-most Timeout and let the outer Timeouts wait until the inner-most Timeout returns. In the above example, it would raise either A or B, not both. The problem with this approach is that if you are rescuing B in the inner block, it never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue B sleep # The outer Timeout waits for the inner timeout, and the inner Timeout never return. So this code never ends. end end end ``` ### Solution 3 Make thread interrupt queue one length. If the target thread has already been `Thread#raise(A)`, the new `Thread#raise(B)` blocks until the target thread processes A. Since there will be no more simultaneous Thread#raise, there will be no more exceptions after the end of the block. The timeout timer thread should be changed in consideration that `Thread#raise` may block. -- https://bugs.ruby-lang.org/

3 5

[ruby-core:123261] [Ruby Bug#21607] require 'concurrent-ruby' causes segfault with Ruby 3.4.6 on linux/i686
by satadru (Satadru Pramanik) 11 Dec '25

11 Dec '25

Issue #21607 has been reported by satadru (Satadru Pramanik). ---------------------------------------- Bug #21607: require 'concurrent-ruby' causes segfault with Ruby 3.4.6 on linux/i686 https://bugs.ruby-lang.org/issues/21607 * Author: satadru (Satadru Pramanik) * Status: Open * ruby -v: ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [i686-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- As mentioned at https://github.com/ruby/ruby/pull/14532#issuecomment-3288983469 chronos@buppie-i686:2.23 M58 /usr/local/lib/crew/packages (master >|SPARSE)$ ruby -e "require 'concurrent-ruby' ; puts 'success'" Segmentation fault This causes a segfault on i686 only on our Chromebrew/i686 systems. armv7l and x86_64 do not have this issue. This may be linked to the update to prism 1.5.x? Docker reproducer on our i686 ChromeOS Milestone 58 based container image: docker run --init --platform linux/386 --rm --net=host -v $(pwd):/output -h $(hostname)-i686 --tmpfs /tmp --ulimit "nofile=$(ulimit -Sn):$(ulimit -Hn)" -it satmandu/crewbuild:alex-i686.m58 # Note the lack of an issue with 3.4.5 with this command: ruby -e "require 'concurrent-ruby' ; puts 'success'" # In that container, upgrade ruby to 3.4.6: CREW_REPO=https://github.com/chromebrew/chromebrew.git CREW_BRANCH=updater-ruby_3.4.6 crew update \ && yes | crew upgrade # Then run the breaking command: ruby -e "require 'concurrent-ruby' ; puts 'success'" # Note the segfault. -- https://bugs.ruby-lang.org/

8 17

[ruby-core:123063] [Ruby Feature#21552] allow String.strip and similar to take a parameter similar to String.delete
by MSP-Greg (Greg L) 11 Dec '25

11 Dec '25

Issue #21552 has been reported by MSP-Greg (Greg L). ---------------------------------------- Feature #21552: allow String.strip and similar to take a parameter similar to String.delete https://bugs.ruby-lang.org/issues/21552 * Author: MSP-Greg (Greg L) * Status: Open ---------------------------------------- Regrading `String.strip` (and `lstrip`, `rstrip`, and `!` versions) Some text data representations differentiate between what one might call vertical and horizontal white space, and the 'strip' methods currently strip both. It would be helpful if they had an optional parameter similar to `String.delete` with a one multi-character selector, so one could do: ```ruby t = str.strip " \t" ``` One can use a regex for this, but this much simpler. -- https://bugs.ruby-lang.org/

7 11