November 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: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

[ruby-core:123813] [Ruby Misc#21688] Ruby::Box maturing path
by zverok (Victor Shepelev) 09 Dec '25

09 Dec '25

Issue #21688 has been reported by zverok (Victor Shepelev). ---------------------------------------- Misc #21688: Ruby::Box maturing path https://bugs.ruby-lang.org/issues/21688 * Author: zverok (Victor Shepelev) * Status: Open ---------------------------------------- A quick couple of questions in the light of upcoming Ruby 4.0 release and `Ruby::Box` being available there (even if as an experimental feature): 1. Should the documentation of the class be available as RDoc? I mean, as standard class documentation at https://docs.ruby-lang.org/en/master/Ruby/Box.html (404 currently). It seems like RDoc-formatted comments are present [in the code](https://github.com/ruby/ruby/blob/master/box.c#L1048) but never rendered. Are PRs to make the docs rendered and/or improve/expand them welcome, or would it be just distracting? 2. Should small(ish) problems/suggestions be reported? Can they be submitted as PRs? (I mean, things like "in some cases, `#inspect` of the class in the Box is weird", and other stuff like this) Or this would be just distracting from the main work? Thanks. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:123835] [Ruby Bug#21694] Crash when looking up super method from BasicObject
by byroot (Jean Boussier) 09 Dec '25

09 Dec '25

Issue #21694 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #21694: Crash when looking up super method from BasicObject https://bugs.ruby-lang.org/issues/21694 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- Initially reported on Reddit by easydwh https://old.reddit.com/r/ruby/comments/1ozhupr/is_a_ruby_segmentation_fault… Repro: ```ruby class BasicObject def basic_call_no_super super end end "test".basic_call_no_super ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123815] [Ruby Misc#21689] DevMeeting-2025-12-11
by mame (Yusuke Endoh) 09 Dec '25

09 Dec '25

Issue #21689 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #21689: DevMeeting-2025-12-11 https://bugs.ruby-lang.org/issues/21689 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2025/12/11 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2025/12/08. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

8 11