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

[ruby-core:121952] [Ruby Bug#21318] Namespaces leak with permanent names
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21318 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21318: Namespaces leak with permanent names https://bugs.ruby-lang.org/issues/21318 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Namespaces are not transparent for this program: ```ruby Module.nesting ``` The nesting is empty or not depending on whether it is being executed under a namespace. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121950] [Ruby Bug#21316] Namespaces leak with permanent names
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21316 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21316: Namespaces leak with permanent names https://bugs.ruby-lang.org/issues/21316 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Namespaces are not transparent for this program ```ruby C = Class.new C.name == 'C' ``` because under a non-main user namespace, the name of `C` has the namespace as a prefix. -- https://bugs.ruby-lang.org/

7 12

[ruby-core:122132] [Ruby Bug#21343] Namespace: singleton classes of root namespace leak between namespaces
by jhawthorn (John Hawthorn) 09 Dec '25

09 Dec '25

Issue #21343 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21343: Namespace: singleton classes of root namespace leak between namespaces https://bugs.ruby-lang.org/issues/21343 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby classes all have singleton classes, those singleton classes have singleton classes, and so on with infinite nesting. Since we don't have infinite resources, we create these lazily. Because of this, only a certain number of singleton classes exist in the root namespace. At a certain depth, mutable singleton classes end up shared between namespaces. ``` ruby File.write("/tmp/ntest.rb", <<~'RUBY') p String.singleton_class.singleton_class::Foo String.singleton_class.singleton_class::Bar = 456 RUBY String.singleton_class.singleton_class::Foo = 123 ns = Namespace.new ns.require("/tmp/ntest.rb") p String.singleton_class.singleton_class::Bar ``` ``` RUBY_NAMESPACE=1 ruby nstest2.rb ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. 123 456 ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122070] [Ruby Feature#21335] Namespaces should be present in the backtrace
by tenderlovemaking (Aaron Patterson) 09 Dec '25

09 Dec '25

Issue #21335 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21335: Namespaces should be present in the backtrace https://bugs.ruby-lang.org/issues/21335 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- Namespaces can call in to other name spaces. I think it might be helpful if namespace information is in the backtrace. For example: ```ruby File.binwrite "foo.rb", <<-eorb class Foo def self.test(ns1, ns2, count) if count == 0 puts caller else if count % 2 == 0 ns1::Foo.test(ns1, ns2, count - 1) else ns2::Foo.test(ns1, ns2, count - 1) end end end end eorb ns1 = Namespace.new ns1.load "foo.rb" ns2 = Namespace.new ns2.load "foo.rb" ns1::Foo.test(ns1, ns2, 10) ``` The output is like this: ``` See doc/namespace.md for known issues, etc. /Users/aaron/git/ruby/exe/ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' /Users/aaron/git/ruby/foo.rb:9:in 'test' /Users/aaron/git/ruby/foo.rb:7:in 'test' ./test.rb:23:in '<main>' ``` `Foo.test` alternates between namespaces when calling a method, but you can't tell from the backtrace. I think we should include namespaces in the backtrace. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:121973] [Ruby Bug#21322] Namespaces and builtin classes as arguments and return values
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21322 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21322: Namespaces and builtin classes as arguments and return values https://bugs.ruby-lang.org/issues/21322 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- @tagomoris thanks for the docs under `doc/namespace.md`. Unless I missed it, I believe there is an edge case related to builtin classes (using the vocabulary there). Consider: ```ruby # test.rb ns = Namespace.new ns.require_relative 'foo' X = 1 ns::C.x(Object) # foo.rb class C def self.x(obj) obj::X end end ``` `obj::X` raises. I believe this is consistent with the feature, but maybe would deserve docs, because from the point of view of the Ruby programmer I am passing an object, no constant name resolution is happening in `foo.rb`. See what I mean? I believe, from my tests, that something analogous happens if `ns::C.x` returns (the namespaced) `Object`. In the main namespace, you don't get the object passed up as-is. I am also curious about how is this implemented (maybe to comment here, not necessarily in the docs). -- https://bugs.ruby-lang.org/

3 8

[ruby-core:124012] [Ruby Misc#21762] Box: Inspect improvements
by zverok (Victor Shepelev) 09 Dec '25

09 Dec '25

Issue #21762 has been reported by zverok (Victor Shepelev). ---------------------------------------- Misc #21762: Box: Inspect improvements https://bugs.ruby-lang.org/issues/21762 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- 1\. Currently, `Ruby::Box` provides an `#inspect` method, and its output is reasonably short yet mysterious: ```ruby Ruby::Box.new #=> #<Namespace:3,user,optional> ``` First, it uses old `Namespace` name instead of `Ruby::Box`. Next, I am not sure how to interpret everything that goes after the class name (reading through `#inspect` [code](https://docs.ruby-lang.org/en/master/Ruby/Box.html#method-i-inspect) gives some insight, bug I am still unsure what should "user" or "optional" mean). 2\. Box doesn't redefine `#to_s`, which leads to this: ```ruby b = Ruby::Box.new puts b # #<#<Class:0x0000788614d88340>:0x000078861444b0e8> # or, more realistically: raise "Something bad happened in #{b}" # Something bad happened in #<#<Class:0x0000788614d88340>:0x000078861444b0e8> (RuntimeError) ``` I think that making `#to_s` an alias to `#inspect` would be reasonable. 3\. In Ruby 4.0.0-preview2, `#inspect` of nested classes was prefixed with `#to_s` of the box. ```ruby b.require('cgi') b.eval('CGI') #=> #<#<Class:0x00007750c2e9d0d8>:0x00007750c20050c0>::CGI ``` While with the current `#to_s` it looked weird, if (2) is fixed, it could become quite reasonable (i.e. if it looked like `<Ruby::Box:1>::CGI`). In the current master, the behavior had changed: ```ruby b.require('cgi') b.eval('CGI') #=> CGI ``` Which is confusing, because it looks like a constant that can be referred from the outer scope, but it is not: ```ruby CGI # uninitialized constant CGI (NameError) require 'cgi' CGI == b.eval('CGI') #=> false ``` Can we reconsider changing inspect back to scoped one? I understand there might be some downsides (like if some library checks the literal value of `#inspect` of something to make decisions about the class identity), but as `Box` is experimental anyway, now might be a good time to investigate upsides/downsides?.. 4\. That's a completely optional proposal, but if the `#inspect`/`#to_s` improvements would be made, can we consider (if it is possible) respecting the Box instance being assigned to a constant? Like it happens with dynamically-generated classes: ```ruby c = Class.new #=> #<Class:0x00007ec030697ef8> C = c # class receives a name c #=> C ``` Together with my point (3), this might lead to pretty clear naming conventions visible in logs and other places, like `OldAPI::SomeLibrary` (where `OldAPI` is a name of a Box, and `SomeLibrary` is loaded there). -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123992] [Ruby Bug#21760] Ruby::Box: a couple of require-related problems
by zverok (Victor Shepelev) 09 Dec '25

09 Dec '25

Issue #21760 has been reported by zverok (Victor Shepelev). ---------------------------------------- Bug #21760: Ruby::Box: a couple of require-related problems https://bugs.ruby-lang.org/issues/21760 * Author: zverok (Victor Shepelev) * Status: Open * ruby -v: 4.0.0dev (2025-12-03T05:16:03Z master 4762f429f4) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I am not sure whether all the problems have the same nature, but putting them together for now. **1. Enabling box breaks `gem`+`require`** Minimal reproducible example: `test.rb`: ```ruby gem 'faraday', '= 2.14.0' require 'faraday' p Faraday::VERSION ``` (Note that there is no explicit use of `Ruby::Box`) Running it with and without `RUBY_BOX`: ```sh $ ruby test.rb "2.14.0" $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/box.md for known issues, etc. test.rb:2:in 'Kernel#require': cannot load such file -- faraday (LoadError) from test.rb:2:in 'Ruby::Box::Loader#require' from test.rb:2:in '<main>' test.rb:2:in 'Kernel#require': cannot load such file -- faraday (LoadError) from test.rb:2:in 'Ruby::Box::Loader#require' from test.rb:2:in '<main>' ``` (sic, the error is printed twice) **2. requiring the same gem from `Box`-loaded file and the main file** `box.rb`: ```ruby require 'faraday' p "In a box: #{Faraday::VERSION}" ``` `main.rb` ```ruby b = Ruby::Box.new b.load('box.rb') require 'faraday' ``` ```sh $ RUBY_BOX=1 ruby main.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/box.md for known issues, etc. "In a box: 2.14.0" main.rb:5:in 'Kernel#require': cannot load such file -- faraday (LoadError) from main.rb:5:in 'Ruby::Box::Loader#require' from main.rb:5:in '<main>' main.rb:5:in 'Kernel#require': cannot load such file -- faraday (LoadError) from main.rb:5:in 'Ruby::Box::Loader#require' from main.rb:5:in '<main>' ``` **3. `Box#require` seem to not be aware of gems** In the example above, we see that Box-loaded file can require a gem. This also works: ```ruby b = Ruby::Box.new b.eval(<<~RUBY) require "faraday" p Faraday::VERSION RUBY ``` (prints "2.14.0" as expected) But this doesn't: ```ruby b = Ruby::Box.new b.require('faraday') ``` ```sh $ RUBY_BOX=1 ruby test.rb ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/language/box.md for known issues, etc. test.rb:3:in 'Ruby::Box#require': cannot load such file -- faraday (LoadError) from test.rb:3:in '<main>' ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124000] [Ruby Bug#21761] NameError: uninitialized constant only when RUBY_BOX=1
by yahonda (Yasuo Honda) 09 Dec '25

09 Dec '25

Issue #21761 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #21761: NameError: uninitialized constant only when RUBY_BOX=1 https://bugs.ruby-lang.org/issues/21761 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 4.0.0dev (2025-12-03T07:14:56Z master 8c3909935e) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- This issue is originally found when I tested Ruby::Box against Rails main branch, I think I have created a repro. ### Steps to reproduce 1. Install Ruby master branch 2. Follow these steps below. ``` git clone https://github.com/yahonda/repro-ruby-box-uninitialized-constant cd repro-ruby-box-uninitialized-constant RUBY_BOX=1 rake ``` ### Expected behavior It should load the configuration as follows. ``` $ RUBY_BOX=0 rake Constants defined: ROOT = /tmp/test FIXTURES_ROOT = /tmp/test/fixtures Running test from Rakefile... --- Loading config.yml with ERB --- YAML content before ERB processing: default: path: <%= FIXTURES_ROOT %>/data name: test_fixture Processing ERB... YAML content after ERB processing: default: path: /tmp/test/fixtures/data name: test_fixture Parsed config: {"default" => {"path" => "/tmp/test/fixtures/data", "name" => "test_fixture"}} SUCCESS: Config loaded successfully $ ``` ### Actual behavior It raises the `NameError: uninitialized constant FIXTURES_ROOT`. ``` $ RUBY_BOX=1 rake /home/yahonda/.local/share/mise/installs/ruby/trunk/bin/ruby: warning: Ruby::Box is experimental, and the behavior may change in the future! See doc/language/box.md for known issues, etc. Constants defined: ROOT = /tmp/test FIXTURES_ROOT = /tmp/test/fixtures Running test from Rakefile... --- Loading config.yml with ERB --- YAML content before ERB processing: default: path: <%= FIXTURES_ROOT %>/data name: test_fixture Processing ERB... ERROR: NameError: uninitialized constant FIXTURES_ROOT (erb):2:in '<main>' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/4.0.0+0/erb.rb:1012:in 'Kernel#eval' /home/yahonda/.local/share/mise/installs/ruby/trunk/lib/ruby/4.0.0+0/erb.rb:1012:in 'ERB#result' /home/yahonda/src/github.com/yahonda/repro-ruby-box-uninitialized-constant/test_box.rb:19:in '<top (required)>' /home/yahonda/src/github.com/yahonda/repro-ruby-box-uninitialized-constant/Rakefile:8:in 'Kernel#require_relative' $ ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123916] [Ruby Bug#21714] Prism and parse.y inconsistency in `def a = a b do 1 end`
by tompng (tomoya ishida) 09 Dec '25

09 Dec '25

Issue #21714 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21714: Prism and parse.y inconsistency in `def a = a b do 1 end` https://bugs.ruby-lang.org/issues/21714 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-26T06:41:42Z master 43ed35de6c) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Endless method definition and command with block are syntax error in parse.y, accepted in Prism. ~~~ruby def a = a b do 1 end ~~~ Related to https://bugs.ruby-lang.org/issues/17398 and https://bugs.ruby-lang.org/issues/21711 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:123915] [Ruby Bug#21713] Prism accepts pattern matching in modifier rescue followed by operators that shouldn't be allowed
by tompng (tomoya ishida) 09 Dec '25

09 Dec '25

Issue #21713 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #21713: Prism accepts pattern matching in modifier rescue followed by operators that shouldn't be allowed https://bugs.ruby-lang.org/issues/21713 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-26T06:41:42Z master 43ed35de6c) +YJIT +MN +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- These are syntax errors in parse.y but accepted in Prism ~~~ruby a rescue b => c in d a rescue b in c.. a rescue b => c.. a rescue b => c::itself a rescue b => c[] a rescue b => c[0] = 1 a rescue b => c ? 1 : 2 a rescue b => c || 2 ~~~ Found by this fuzzing script https://gist.github.com/tompng/551777b9b850b0428c9062745cf763db -- https://bugs.ruby-lang.org/

2 1