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

[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

[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:124070] [Ruby Misc#21769] Use "vX.Y.Z" instead of "vX_Y_Z" as tag names on ruby.git
by k0kubun (Takashi Kokubun) 12 Dec '25

12 Dec '25

Issue #21769 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Misc #21769: Use "vX.Y.Z" instead of "vX_Y_Z" as tag names on ruby.git https://bugs.ruby-lang.org/issues/21769 * Author: k0kubun (Takashi Kokubun) * Status: Open ---------------------------------------- ## Proposal * Use `vX.Y.Z` (e.g. `v4.0.0`) instead of `vX_Y_Z` (e.g. `v4_0_0`) as git tag names from Ruby 4.0.0 * Also use `-` for preview/rc releases, e.g. `v4.0.0-rc1` instead of `v4_0_0_rc1` ## Motivation * Inconsistent version formats and the need of conversion make the release workflow implementation a little complicated and hard to read. * As a release manager, I don't want to spend time figuring out which version format is right for each CLI. ## Background * Release tarball URLs already follow the proposed format (without `v`), e.g. `ruby-4.0.0-preview2.tar.gz`. * Historically, we used `vX_Y_Z` because CVS didn't allow the use of `.` in tag names. We no longer need the workaround for Git. * > https://www.gnu.org/software/trans-coord/manual/cvs/html_node/Tags.html > Tag names must start with an uppercase or lowercase letter and can contain uppercase and lowercase letters, digits, ‘-’, and ‘_’. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:124149] [Ruby Misc#21774] [ANN] Rename the `v4_0_0_preview2` git tag to `v4.0.0-preview2`
by k0kubun (Takashi Kokubun) 11 Dec '25

11 Dec '25

Issue #21774 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Misc #21774: [ANN] Rename the `v4_0_0_preview2` git tag to `v4.0.0-preview2` https://bugs.ruby-lang.org/issues/21774 * Author: k0kubun (Takashi Kokubun) * Status: Open * Assignee: k0kubun (Takashi Kokubun) ---------------------------------------- ## Changes As per [Misc #21769], we'll rename the `v4_0_0_preview2` tag to `v4.0.0-preview2` on ruby.git. ## Operations To minimize its potential impact, I'll work on it in the following order: 1. Push a new tag `v4.0.0-preview2`. * Publish a GitHub release entry with `v4.0.0-preview2`. * Remove a duplicated GitHub release from `v4_0_0_preview2` while still not deleting the git tag. 2. Update known `v4_0_0_preview2` references to `v4.0.0-preview2` just in case. * It's referenced in repositories like `ruby/www.ruby-lang.org`, `ruby/rbs`, and `docker-library/ruby`. 3. Delete the old `v4_0_0_preview2` git tag. -- https://bugs.ruby-lang.org/

1 3

[ruby-core:123990] [Ruby Bug#21759] `test_fork.rb:78` is failing with `RUBY_MN_THREADS=1`
by hsbt (Hiroshi SHIBATA) 11 Dec '25

11 Dec '25

Issue #21759 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21759: `test_fork.rb:78` is failing with `RUBY_MN_THREADS=1` https://bugs.ruby-lang.org/issues/21759 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-01T18:02:35Z master f92001344d) +YJIT +MN +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following failure of `make btest` is happend with `RUBY_MN_THREADS=1`. ``` #289 test_fork.rb:78: def now = Process.clock_gettime(Process::CLOCK_MONOTONIC) Thread.new do loop { sleep 0.0001 } end 10.times do pid = fork{ exit!(0) } deadline = now + 10 while true _, status = Process.waitpid2(pid, Process::WNOHANG) break if status if now > deadline Process.kill(:KILL, pid) raise "failed" end sleep 0.001 end unless status.success? raise "child exited with status #{status}" end (...snip) #=> #<Assertion::Timeout: timed out after 180 seconds> (expected "ok") [Bug #20670] ``` This failure occurred 4 times out of 5 times. But I couldn't reproduce this when I removed `RUBY_MN_THREADS` at 5 times. -- https://bugs.ruby-lang.org/

2 3