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

[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) 08 Dec '25

08 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

[ruby-core:121389] [Ruby Bug#21187] Strings concatenated with `\` getting frozen with literal hashes (PRISM only)
by LocoDelAssembly 08 Dec '25

08 Dec '25

Issue #21187 has been reported by LocoDelAssembly (Hernán Pereira). ---------------------------------------- Bug #21187: Strings concatenated with `\` getting frozen with literal hashes (PRISM only) https://bugs.ruby-lang.org/issues/21187 * Author: LocoDelAssembly (Hernán Pereira) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When the first elements of a literal hash are strings that are concatenated with `\`, those elements are flagged with `PM_NODE_FLAG_STATIC_LITERAL` and a special optimization that I believe was introduced in https://github.com/ruby/ruby/commit/8080de04be8e99e71309745822a9d436cc4ae37c causes the strings to be frozen. Reproduction === test.rb ``` a = { a: 'one' \ 'two', b: 'three' \ 'four', c: 'five', d: 'six' \ 'seven' } b = { a: 'one', b: 'two' \ 'three' } puts "a = #{a.map { |k,v| {k => v.frozen?} }}" puts "b = #{b.map { |k,v| {k => v.frozen?} }}" ``` With prism: ``` $ ruby test.rb a = [{a: true}, {b: true}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` With parse.y: ``` $ ruby --parser=parse.y test.rb a = [{a: false}, {b: false}, {c: false}, {d: false}] b = [{a: false}, {b: false}] ``` (Notice `b` hash is unaffected in both parsers) Not sure if this is just part of undefined behavior or this is indeed a bug. Assigning a string concatenated with `\` to a variable doesn't make it frozen, to the best of my knowledge this seems to be hash-specific. -- https://bugs.ruby-lang.org/

6 13

[ruby-core:123884] [Ruby Bug#21705] `UNIXServer.open(nil)` segfaults on Windows
by nobu (Nobuyoshi Nakada) 08 Dec '25

08 Dec '25

Issue #21705 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21705: `UNIXServer.open(nil)` segfaults on Windows https://bugs.ruby-lang.org/issues/21705 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- It should check the type of the argument and coercion before converting the encoding. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123769] [Ruby Bug#21680] Integer#digits bug starting from Ruby 3.1
by sigsys (Math Ieu) 08 Dec '25

08 Dec '25

Issue #21680 has been reported by sigsys (Math Ieu). ---------------------------------------- Bug #21680: Integer#digits bug starting from Ruby 3.1 https://bugs.ruby-lang.org/issues/21680 * Author: sigsys (Math Ieu) * Status: Open * ruby -v: ruby 3.3.10 (2025-10-23 revision 343ea05002) [amd64-freebsd14] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ``` (2**512).digits(256).last ``` The result was 1 on Ruby 3.0. Starting from Ruby 3.1 it turned to 256 (which can't possibly be right). -- https://bugs.ruby-lang.org/

4 3