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

[ruby-core:124229] [Ruby Feature#6012] Proc#source_location also return the column
by mame (Yusuke Endoh) 16 Dec '25

16 Dec '25

Issue #6012 has been updated by mame (Yusuke Endoh). Status changed from Closed to Open 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: * Unclear use cases * The description of #6012 lacked a use case. * The use case presented in #21005 was not convincing. * Difficulty in changing `Binding#source_location` (#6012#note-24, #21005#note-19) * `Binding#source_location` still returns `[file, lineno]`. * Implementation issues: It was challenging to preserve the location information of `Kernel#binding` calls within the ISeq. * Compatibility issues: `eval(code, nil, *binding.source_location)` is used in several gems; adding column information would break them. * Related issues: * We may need to adjust Proc#source_location's position (#21784). * We need to discuss column units (bytes vs characters) (#21783). * Timing: We can still revert without compatibility issues at this point. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115715 * 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:124220] [Ruby Feature#6012] Proc#source_location also return the column
by matz (Yukihiro Matsumoto) 15 Dec '25

15 Dec '25

Issue #6012 has been updated by matz (Yukihiro Matsumoto). Although last minute, we will cancel this feature in 4.0 because of design ambiguities such as whether to return column positions in bytes or characters as in #21783. Matz. ---------------------------------------- Feature #6012: Proc#source_location also return the column https://bugs.ruby-lang.org/issues/6012#change-115703 * Author: rogerdpack (Roger Pack) * Status: Closed * 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: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

[ruby-core:124209] [Ruby Feature#8948] Frozen regex
by Eregon (Benoit Daloze) 15 Dec '25

15 Dec '25

Issue #8948 has been updated by Eregon (Benoit Daloze). Right, it's too late for 4.0, OK. > Frankly, I don't think freezing the Regexp objects is worth the effort/trouble. I already did the implementation effort so that part is fine. I think it's worth it for consistency and clean semantics, it's much better to explain "all Regexp are frozen" rather than "Regexp is partially frozen, literals are frozen, non-literals are not, but semantically a Regexp is conceptually immutable, we only kept some instances mutable for some rare gems relying on it". Also TruffleRuby already enforce all Regexps to be frozen, so it's a way to be more compatible between Ruby implementations (it's basically infeasible to support a mix of mutable & non-mutable Regexps in TruffleRuby). And of course it's also good for Ractor where then we can say "all Regexps are shareable" vs "some are, some are not". It's just cleaner overall. > Here is the code we found in the dev meeting: Thanks. The `mongo-ruby-driver` is deprecated and seems of dubious value, I think it's not a big concern. I don't understand the use-case in `wallaby-rails`, it's called `LazyRegexp` but it creates the Regexp object eagerly. Also the `@lazy_source` ivar seems to just hold the source, which can be retrieved via `Regexp#source`. mame (Yusuke Endoh) wrote in #note-31: > Also, your PR changes the behavior of `Marshal.load` for a Regexp with encoding: > > ```diff > - assert_equal(/u/, Marshal.load("\004\bI/\a\\u\000\006:\016@encoding\"\vEUC-JP")) > + assert_raise(FrozenError) { Marshal.load("\004\bI/\a\\u\000\006:\016@encoding\"\vEUC-JP") } > ``` > > This incompatibility should be fixed. Also, as a general rule, please clearly state when a PR includes such known incompatibilities. Right, I should have left a comment about it on the PR, sorry. I think that is not reasonable to support, it's actually an `@encoding` ivar on the Regexp object which has no effect on `Regexp#encoding`: ``` irb(main):001> r=Marshal.load("\004\bI/\a\\u\000\006:\016@encoding\"\vEUC-JP") => /u/ irb(main):002> r.instance_variables => [:@encoding] irb(main):003> r.encoding => #<Encoding:US-ASCII> ``` Hence a FrozenError seems appropriate for that case. I would like to try this again in early 2026 / for Ruby 4.1. ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-115691 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Assignee: Eregon (Benoit Daloze) ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124201] [Ruby Bug#21782] Ractor::IsolationError reports incorrect path for constants found through upwards search
by osyoyu (Daisuke Aritomo) 15 Dec '25

15 Dec '25

Issue #21782 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Bug #21782: Ractor::IsolationError reports incorrect path for constants found through upwards search https://bugs.ruby-lang.org/issues/21782 * Author: osyoyu (Daisuke Aritomo) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-15T07:05:21Z master 5a4faaaeb1) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ractor::IsolationError is raised when non-main Ractors attempt access to non-shareable constants. The message contains the path to the constant which triggered the violation. However, the path is incorrect when the constant was resolved through recursive search. ## Repro Run the this Ruby program: ```ruby TOPLEVEL = [1] module M def self.f TOPLEVEL end end Ractor.new { M.f }.value ``` ### Expected Raises Ractor::IsolationError reporting that illegal access occured on `Object::TOPLEVEL` or `TOPLEVEL` ``` bug.rb:5:in 'M.f': can not access non-shareable objects in constant Object::TOPLEVEL by non-main Ractor. (Ractor::IsolationError) from bug.rb:9:in 'block in <main>' ``` ### Actual Raises Ractor::IsolationError reporting that illegal access occured on `M::TOPLEVEL`, which is incorrect. `TOPLEVEL` cannot be accessed as `M::TOPLEVEL`. ``` bug.rb:5:in 'M.f': can not access non-shareable objects in constant M::TOPLEVEL by non-main Ractor. (Ractor::IsolationError) from bug.rb:9:in 'block in <main>' ``` ## Suspected code This message is constructed in `rb_const_get_0()` defined in variable.c. ```c static VALUE rb_const_get_0(VALUE klass, ID id, int exclude, int recurse, int visibility) { VALUE c = rb_const_search(klass, id, exclude, recurse, visibility); if (!UNDEF_P(c)) { if (UNLIKELY(!rb_ractor_main_p())) { if (!rb_ractor_shareable_p(c)) { rb_raise(rb_eRactorIsolationError, "can not access non-shareable objects in constant %"PRIsVALUE"::%s by non-main Ractor.", rb_class_path(klass), rb_id2name(id)); } } return c; } return rb_const_missing(klass, ID2SYM(id)); } ``` The path part is built as `rb_class_path(klass)`, but `klass` may not be the module/class which the constant belongs, when the constant was found through recursive search in `rb_const_search`. -- https://bugs.ruby-lang.org/

1 1

[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:124183] [Ruby Bug#21778] Binding#eval vs implicit parameters
by zverok (Victor Shepelev) 14 Dec '25

14 Dec '25

Issue #21778 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #21778: Binding#eval vs implicit parameters https://bugs.ruby-lang.org/issues/21778 * Author: zverok (Victor Shepelev) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- This works: ```ruby proc { |x| binding.eval('x') }.call(1) #=> 1 ``` This doesn't (neither with numbered parameters, nor with `it`): ```ruby proc { _1; binding.eval('_1') }.call(1) # undefined local variable or method '_1' for main (NameError) ``` ...even though binding is "aware" of `_1` existence with `implicit_parameters`. I don't think it is a "huge" bug or even practical one. I just wanted to highlight that maybe `Binding#eval` lacks some context that it should have?.. Or maybe it is my misunderstanding of `Binding#eval`, I expected that any code that will work in the place of a binding literally, should work in `eval` as well. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123546] [Ruby Bug#21648] [prism] ruby crashes for `for * in [10]; end`
by Earlopain (Earlopain _) 13 Dec '25

13 Dec '25

Issue #21648 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21648: [prism] ruby crashes for `for * in [10]; end` https://bugs.ruby-lang.org/issues/21648 * Author: Earlopain (Earlopain _) * Status: Open * ruby -v: ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```sh $ ruby -e "for * in [10]; end" -e:1: [BUG] Stack consistency error (sp: 15, bp: 14) ruby 3.4.6 (2025-09-16 revision dbd83256b1) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0004 p:0008 s:0015 e:000013 BLOCK -e:1 [FINISH] c:0003 p:---- s:0010 e:000009 CFUNC :each c:0002 p:0005 s:0006 e:000005 EVAL -e:1 [FINISH] c:0001 p:0000 s:0003 E:0014c0 DUMMY [FINISH] ... ``` `parse.y` handles this ---Files-------------------------------- crash.txt (19.7 KB) -- https://bugs.ruby-lang.org/

2 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:124157] [Ruby Bug#21776] Binding#local_variable_defined? still supports numbered parameters
by zverok (Victor Shepelev) 12 Dec '25

12 Dec '25

Issue #21776 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #21776: Binding#local_variable_defined? still supports numbered parameters https://bugs.ruby-lang.org/issues/21776 * Author: zverok (Victor Shepelev) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-11T18:57:06Z master d02c971574) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- On the freshest `master`: ```ruby [1].each {_1; p binding.local_variable_defined?(:_1) } #=> true ``` It is inconsistent with changes in `#local_variables`/`#local_variable_get`/`#local_variable_set`. And inconsistent with handling of `it`: ```ruby [1].each { it; p binding.local_variable_defined?(:it) } #=> false ``` -- https://bugs.ruby-lang.org/

2 2