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

[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

[ruby-core:122240] [Ruby Bug#21363] `Namespace.current` should always return the Namespace in which it was defined
by tenderlovemaking (Aaron Patterson) 09 Dec '25

09 Dec '25

Issue #21363 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Bug #21363: `Namespace.current` should always return the Namespace in which it was defined https://bugs.ruby-lang.org/issues/21363 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-22T23:07:21Z rm-assertion 17e71c7a24) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I think `Namespace.current` should always return the namespace in which it was defined. Here is an example to demonstrate what I mean: ```ruby File.binwrite("ns.rb", <<-RUBY) # namespace 3 module M def self.test p Namespace.current end TEST = -> { p Namespace.current } end RUBY ns = Namespace.new ns.load "./ns.rb" p Namespace.current ns::M.test ns::M::TEST.call ``` I expect the output of `ns::M.test` and `ns::M::TEST.call` to be the same. Instead the output is like this: ``` #<Namespace:2,user,main> #<Namespace:3,user,optional> #<Namespace:2,user,main> ``` I think a method and lambda defined in the same namespace should return the same value for `Namespace.current` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:122114] [Ruby Bug#21341] `Namespace is not a module (TypeError)` without enabling the namespace
by yahonda (Yasuo Honda) 09 Dec '25

09 Dec '25

Issue #21341 has been reported by yahonda (Yasuo Honda). ---------------------------------------- Bug #21341: `Namespace is not a module (TypeError)` without enabling the namespace https://bugs.ruby-lang.org/issues/21341 * Author: yahonda (Yasuo Honda) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-15T08:25:56Z master 427ede2dde) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Ruby on Rails test case has the `module Namespace`. https://github.com/rails/rails/blob/main/activemodel/test/validators/namesp… ```ruby module Namespace class EmailValidator < ::EmailValidator end end ``` This code fails against Ruby 3.5.0dev without enabling the namespace feature. ### Steps to reproduce ```ruby $ ruby -ve 'module Namespace; end' ``` ### Expected behavior It should run without errors. ### Actual behavior It raises the TypeError. ```ruby $ ruby -ve 'module Namespace; end' ruby 3.5.0dev (2025-05-15T08:25:56Z master 427ede2dde) +PRISM [x86_64-linux] -e:1:in '<main>': Namespace is not a module (TypeError) ruby:0: previous definition of Namespace was here ``` Raising this TypeError with RUBY_NAMESPACE=1 looks expected to me. ```ruby $ RUBY_NAMESPACE=1 ruby -ve 'module Namespace; end' ruby 3.5.0dev (2025-05-15T08:25:56Z master 427ede2dde) +PRISM [x86_64-linux] ruby: warning: Namespace is experimental, and the behavior may change in the future! See doc/namespace.md for known issues, etc. -e:1:in '<main>': Namespace is not a module (TypeError) ruby:0: previous definition of Namespace was here ``` -- https://bugs.ruby-lang.org/

5 8

[ruby-core:121955] [Ruby Bug#21320] Namespaces leak with constant lookup
by fxn (Xavier Noria) 09 Dec '25

09 Dec '25

Issue #21320 has been reported by fxn (Xavier Noria). ---------------------------------------- Bug #21320: Namespaces leak with constant lookup https://bugs.ruby-lang.org/issues/21320 * Author: fxn (Xavier Noria) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- The following program ```ruby X = :top class C X = :super end class D < C p X end ``` prints `:super` normally, and `:top` if running under a namespace. -- https://bugs.ruby-lang.org/

3 4

[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