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

[ruby-core:122296] [Ruby Bug#21374] FrozenError message is inconsistent when a singleton method is defined on a frozen object
by andrykonchin (Andrew Konchin) 23 Nov '25

23 Nov '25

Issue #21374 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #21374: FrozenError message is inconsistent when a singleton method is defined on a frozen object https://bugs.ruby-lang.org/issues/21374 * Author: andrykonchin (Andrew Konchin) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I would expect a message to contain an object class (e.g. `can't modify frozen <class>: <object#inspect>`) when an ordinary frozen object (non a module or class) is being modified. It works this way in the following example: ```ruby object = []; object.freeze; object.instance_variable_set(:@a, 42) # (irb):5:in `instance_variable_set': can't modify frozen Array: [] (FrozenError) ``` But it doesn't in the following example: ```ruby object = []; object.freeze; def object.x; end # (irb):4:in `<main>': can't modify frozen object: [] (FrozenError) ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:123871] [Ruby Feature#21700] `IO::Buffer.map`: offset argument is "broken" and needs to be made more useful
by trinistr (Alexander Bulancov) 21 Nov '25

21 Nov '25

Issue #21700 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Feature #21700: `IO::Buffer.map`: offset argument is "broken" and needs to be made more useful https://bugs.ruby-lang.org/issues/21700 * Author: trinistr (Alexander Bulancov) * Status: Open ---------------------------------------- *This was supposed to be a bug report, but it turned into a feature request halfway through.* `IO::Buffer.map` supports `size` and `offset` arguments to localize buffer to a specific part of mapped file. While `size` works fine, specifying `offset` as anything but 0 is a recipe for disaster. 1. It is practically undocumented. This is it currently: "Optional size and offset of mapping can be specified." While `size` can be whatever user desires, `offset` can only be set to specific values. It was *very* surprising when I started testing it, as I expected it to behave similar to size and offset of a slice. Which values are allowed? That's the next point. 2. Possible values for `offset` are highly platform-dependent. - On Linux it must be a multiple of page size. (https://www.man7.org/linux/man-pages/man2/mmap.2.html) - On macOS it can be any value? manpage doesn't specify exactly. (https://developer.apple.com/library/archive/documentation/System/Conceptual… (I looked at the manpage on a mac, seems to be the same.)) - On Windows it must be a multiple of some value that *isn't* page size and page size doesn't work here. StackOverflow says it's 64 kB, but that didn't work for me. (See dwFileOffsetLow in https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-…) - On other systems? Who knows. 3. On macOS, a buffer successfully created with an offset crashes on read. I don't know why, it's exactly the same file, size and offset that works on Ubuntu, and the read is bounded. 4. Currently, offset doesn't change the buffer's size if unspecified, leading to crashes. I will be making a PR addressing this but still. 5. All of this makes offset unpractical to test, leading to all kinds of problems. So the problem is: this argument is a very low-level detail that requires significant knowledge of all platforms your code may be ever deployed to, even if strictly Ruby is used (no C API), with unexpectedly high footgun potential. I understand that IO::Buffer is a lower-level class, but this seems too much. I propose to make `offset` argument into a convenience for users, allowing any reasonable value (i.e inside the file). Behind the scenes, we can use the native offset for efficieny, on platforms where it works well, but the user API would be decoupled from this. However, I'm not particularly familiar with Ruby internals, so I can't tell how viable this is. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123737] [Ruby Feature#21675] Advent of Pattern Matching
by baweaver (Brandon Weaver) 20 Nov '25

20 Nov '25

Issue #21675 has been reported by baweaver (Brandon Weaver). ---------------------------------------- Feature #21675: Advent of Pattern Matching https://bugs.ruby-lang.org/issues/21675 * Author: baweaver (Brandon Weaver) * Status: Open ---------------------------------------- Ruby pattern matching is a very useful feature, but many of the core classes to not leverage it currently. Given this I would like to directly invest in opening PRs to add this functionality and see how many cases we can reasonably add as we approach Ruby 4.0. I have already started here: * `Gem::Version` - https://github.com/ruby/ruby/pull/15109 * `Net::HTTPResponse` - https://github.com/ruby/ruby/pull/15110 * `Net::HTTPGenericRequest` - https://github.com/ruby/ruby/pull/15111 But what I am currently considering looking at first are: * `Pathname` - Path manipulation is ubiquitous. Pattern matching on path components (dirname, basename, extname) would simplify file handling logic. * `URI::Generic` - URL routing and parsing would benefit from matching on scheme, host, port, and path components. * `IPAddr` - Network programming would benefit from matching on IP address components and families for filtering and routing logic. * `File::Stat` - File metadata inspection is common. Matching on size, mode, timestamps, and file type predicates would simplify permission and type checks. * `Process::Status` - Process exit status checking is verbose. Matching on exitstatus, signals, and success state would clarify intent. * `Addrinfo` - Socket programming would benefit from matching on address family, socket type, and IP address/port for connection handling. * `OpenSSL::X509::Certificate` - Certificate validation logic could be cleaner with matching on subject, issuer, and validity dates. * `OpenSSL::X509::Name` - Distinguished name parsing for certificate handling would benefit from component extraction. * `Gem::Requirement` - Complements Gem::Version for dependency management patterns. * `Gem::Specification` - Gem metadata inspection in tooling could benefit from structured matching. If this is of interest I will start looking for more areas as well. My goal is to make this a feature that is well supported throughout common libraries in Ruby. We can use this issue as a potential staging ground for discussion of what else might make sense. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:123836] [Ruby Feature#21695] Optimizing Ruby performance with Ruby itself instead of Rust
by fredlinhares (Frederico Linhares) 20 Nov '25

20 Nov '25

Issue #21695 has been reported by fredlinhares (Frederico Linhares). ---------------------------------------- Feature #21695: Optimizing Ruby performance with Ruby itself instead of Rust https://bugs.ruby-lang.org/issues/21695 * Author: fredlinhares (Frederico Linhares) * Status: Open ---------------------------------------- I am using ERB on top of C for a game I am making now. We can use the tool to improve the productivity, memory safety, and runtime speed for Ruby. It can also replace a Rust JIT compiler for better results. The only problem is that it requires some level of manual memory management, while Rust does it all for you. If I demonstrate that it is better than Rust in practice, would you be willing to incorporate it into the Ruby language? I want to know because making it more generic will require more effort from me; if you are not interested, I won’t make the tool public. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:119239] [Ruby master Feature#20750] Expose ruby_thread_has_gvl_p in ruby/thread.h
by kbrock (Keenan Brock) 19 Nov '25

19 Nov '25

Issue #20750 has been reported by kbrock (Keenan Brock). ---------------------------------------- Feature #20750: Expose ruby_thread_has_gvl_p in ruby/thread.h https://bugs.ruby-lang.org/issues/20750 * Author: kbrock (Keenan Brock) * Status: Open ---------------------------------------- Hello All, I'm hoping we can make `ruby_thread_has_gvl_p` a public method and no longer experimental. I saw the following code in a gem that was not compiling with ruby 3.3: ``` c // int ruby_thread_has_gvl_p(void); // <== line of concern if (ruby_thread_has_gvl_p()) { method_call(&context); } else { rb_thread_call_with_gvl(method_call, &context); } ``` 400 unique projects on github added the line listed above to fix compilation. [1] Some of the projects detected the method first in `extconf.rb`, but a majority just referenced it. `ffi` used to have the detection code but dropped it since the method was in all supported ruby versions. It feels like this method is now part of the undocumented public interface. My suggestion is to add the method to the real public interface in `ruby/thread.h`. PR with possible solution: https://github.com/ruby/ruby/pull/11619 Also included a patch if that is easier Thank you for your consideration, Keenan Timeline: - Dec 30 2008 - `rb_thread_call_with_gvl` introduced via 9c04a06 [2] - Jan 12 2009 - `ruby_thread_has_gvl_p` introduced via 6f09fc2 [4] - Jul 18 2012 - `rb_thread_call_with_gvl` made public via e9a91d2 [3] Current references to code: `rb_thread_call_with_gvl` [5] `ruby_thread_has_gvl_p` [6]: [1]: https://github.com/search?q=ruby_thread_has_gvl_p+language%3AC++NOT+is%3Afo… [2]: https://github.com/ruby/ruby/commit/9c04a0647fb99f7554cb2e04385ddbb970631e02 [3]: https://github.com/ruby/ruby/commit/e9a91d2c95dfe22ad0487952f7a1053ef9a5fd16 [4]: https://github.com/ruby/ruby/commit/6f09fc2efd1915c4337ce6dded52a8a8771c3222 [5]: https://github.com/ruby/ruby/blob/master/thread.c#L1878 [6]: https://github.com/ruby/ruby/blob/master/thread.c#L1923 ---Files-------------------------------- 11618.patch (3.18 KB) -- https://bugs.ruby-lang.org/

3 8

[ruby-core:123856] [Ruby Bug#21698] Should simple ArgumentError refer to Object?
by vo.x (Vit Ondruch) 19 Nov '25

19 Nov '25

Issue #21698 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #21698: Should simple ArgumentError refer to Object? https://bugs.ruby-lang.org/issues/21698 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 4.0.0dev (2025-11-18 master 85abc59c32) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Having this simple test file: ~~~ $ cat test.rb def foo(x, y) end foo(1) ~~~ This is the Ruby 3.4 behavior: ~~~ $ ruby --disable-gems test.rb test.rb:1:in 'foo': wrong number of arguments (given 1, expected 2) (ArgumentError) from test.rb:4:in '<main>' $ ruby -v ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x86_64-linux] ~~~ While Ruby 4.0 refers to `Object` in the backtrace: ~~~ $ ruby --disable-gems test.rb test.rb:1:in 'Object#foo': wrong number of arguments (given 1, expected 2) (ArgumentError) from test.rb:4:in '<main>' $ ruby -v ruby 4.0.0dev (2025-11-18 master 85abc59c32) +PRISM [x86_64-linux] ~~~ While this is certainly correct, I also think it is a bit confusing, because the code does not explicitly refer to `Object`. This likely comes as a result of #21543, but I think that there the original proposal for such simple case was different. I am also not convinced that the `did_you_mean` output really helps: ~~~ $ ruby test.rb test.rb:1:in 'Object#foo': wrong number of arguments (given 1, expected 2) (ArgumentError) caller: test.rb:4 | foo(1) ^^^ callee: test.rb:1 | def foo(x, y) ^^^ from test.rb:4:in '<main>' ~~~ But maybe I should just get used to it 🤷 Just FTR, I have come here trying to fix the following Sass gem test suite error on Fedora: ~~~ 1) Failure: SassScriptTest#test_shallow_argument_error_unwrapped [test/sass/script_test.rb:704]: --- expected +++ actual @@ -1 +1,3 @@ -"wrong number of arguments (1 for 0) for `arg-error'" +# encoding: ASCII-8BIT +# valid: true +"wrong number of arguments (given 1, expected 0) for `arg-error'" ~~~ The problem there is that Sass is trying to parse the backtrace: https://github.com/sass/ruby-sass/blob/7a50eae567260a23d3bbf4d5aaf1a76db43d… and changes like these breaks the compatibility. We already had to apply some [changes for Ruby 3.4](https://src.fedoraproject.org/rpms/rubygem-sass/blob/rawhide/f/rubygem… and this is yet another breakage. This is the actual difference: ~~~ --- ruby-3.4 +++ ruby-4.0 @@ -1,3 +1,3 @@ > e.backtrace => -["/builddir/build/BUILD/rubygem-sass-3.7.4-build/sass-3.7.4/usr/share/gems/gems/sass-3.7.4/test/sass/script_test.rb:11:in 'arg_error'", +["/builddir/build/BUILD/rubygem-sass-3.7.4-build/sass-3.7.4/usr/share/gems/gems/sass-3.7.4/test/sass/script_test.rb:11:in 'Sass::Script::Functions::UserFunctions#arg_error'", ~~~ Contrary to my original point, in this case the backtrace might be better. Maybe this needs more polishing? -- https://bugs.ruby-lang.org/

3 4

[ruby-core:121837] [Ruby Feature#21311] Namespace on read (revised)
by tagomoris (Satoshi Tagomori) 19 Nov '25

19 Nov '25

Issue #21311 has been reported by tagomoris (Satoshi Tagomori). ---------------------------------------- Feature #21311: Namespace on read (revised) https://bugs.ruby-lang.org/issues/21311 * Author: tagomoris (Satoshi Tagomori) * Status: Open ---------------------------------------- This replaces #19744 ## Concept This proposes a new feature to define virtual top-level namespaces in Ruby. Those namespaces can require/load libraries (either .rb or native extension) separately from other namespaces. Dependencies of required/loaded libraries are also required/loaded in the namespace. This feature will be disabled by default at first, and will be enabled by an env variable `RUBY_NAMESPACE=1` as an experimental feature. (It could be enabled by default in the future possibly.) ### "on read" approach The "on write" approach here is the design to define namespaces on the loaded side. For example, Java packages are defined in the .java files and it is required to separate namespaces from each other. It can be implemented very easily, but it requires all libraries to be updated with the package declaration. (In my opinion, it's almost impossible in the Ruby ecosystem.) The "on read" approach is to create namespaces and then require/load applications and libraries in them. Programmers can control namespace separation at the "read" time. So, we can introduce the namespace separation incrementally. ## Motivation The "namespace on read" can solve the 2 problems below, and can make a path to solve another problem: * Avoiding name conflicts between libraries * Applications can require two different libraries safely which use the same module name. * Avoiding unexpected globally shared modules/objects * Applications can make an independent/unshared module instance. * Multiple versions of gems can be required * Application developers will have fewer version conflicts between gem dependencies if rubygems/bundler will support the namespace on read. (Support from RubyGems/Bundler and/or other packaging systems will be needed) For the motivation details, see [Feature #19744]. ## How we can use Namespace ```ruby # app1.rb PORT = 2048 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 2048 # app2.rb class Number def double = self * 2 end PORT = 2048.double class App def self.port = ::PORT def val = PORT.double.to_s end p App.port # 4096 # main.rb - executed as `ruby main.rb` ns1 = Namespace.new ns1.require('./app1') # 2048 ns2 = Namespace.new ns2.require('./app2') # 4096 PORT = 8080 class App def self.port = ::PORT def val = PORT.to_s end p App.port # 8080 p App.val # "8080" p ns1::App.port # 2048 p ns1::App.val # "2048" p ns2::App.port # 4096 p ns2::App.val # "8192" 1.double # NoMethodError ``` ## Namespace specification ### Types of namespaces There are two namespace types, "root" and "user" namespace. "Root" namespace exists solely in a Ruby process, and "user" namespaces can be created as many as Ruby programmers want. ### Root namespace Root namespace is a unique namespace to be defined when a Ruby process starts. It only contains built-in classes/modules/constants, which are available without any `require` calls, including RubyGems itself (when `--disable-gems` is not specified). ### User namespace User namespace is a namespace to run users' Ruby scripts. The "main" namespace is the namespace to run the user's `.rb` script specified by the `ruby` command-line argument. Other user namespaces ("optional" namespaces) can be created by `Namespace.new` call. In user namespace (both main and optional namespaces), built-in class/module definitions are copied from the root namespace, and other new classes/modules are defined in the namespace, separately from other (root/user) namespaces. The newly defined classes/modules are top-level classes/modules in the main namespace like `App`, but in optional namespaces, classes/modules are defined under the namespace (subclass of Module), like `ns::App`. In that namespace `ns`, `ns::App` is accessible as `App` (or `::App`). There is no way to access `App` in the main namespace from the code in the different namespace `ns`. ### Constants, class variables and global variables Constants, Class variables of built-in classes and global variables are also separated by namespace. Values set to class/global variables in a namespace are invisible in other namespaces. ### Methods and procs Methods defined in a namespace run with the defined namespace, even when called from other namespaces. Procs created in a namespace run with the defined namespace too. ### Dynamic link libraries Dynamic link libraries (typically .so files) are also loaded in namespaces as well as .rb files. ### Open class (Changes on built-in classes) In user namespaces, built-in class definitions can be modified. But those operations are processed as copy-on-write of class definition from the root namespace, and the changed definitions are visible only in the (user) namespace. Definitions in the root namespace are not modifiable from other namespaces. Methods defined in the root namespace run only with root-namespace definitions. ## Enabling Namespace Specify `RUBY_NAMESPACE=1` environment variable when starting Ruby processes. `1` is the only valid value here. Namespace feature can be enabled only when Ruby processes start. Setting `RUBY_NAMESPACE=1` after starting Ruby scripts performs nothing. ## Pull-request https://github.com/ruby/ruby/pull/13226 -- https://bugs.ruby-lang.org/

19 110

[ruby-core:123854] [Ruby Bug#21697] `nmake up` will update broken `revision.h`
by hsbt (Hiroshi SHIBATA) 19 Nov '25

19 Nov '25

Issue #21697 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21697: `nmake up` will update broken `revision.h` https://bugs.ruby-lang.org/issues/21697 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In 4.0.0-preview2 package, `nmake up` generate the broken `revision.h`. I could reproduce this: ``` PS C:\Users\hsbt\Downloads> Invoke-WebRequest https://cache.ruby-lang.org/pub/ruby/4.0/ruby-4.0.0-preview2.zip -OutFile ruby-4.0.0-preview2.zip (snip) PS C:\Users\hsbt\Downloads> unzip .\ruby-4.0.0-preview2.zip Archive: ./ruby-4.0.0-preview2.zip creating: ruby-4.0.0-preview2/ (snip) inflating: ruby-4.0.0-preview2/zjit.rbinc PS C:\Users\hsbt\Downloads> cd .\ruby-4.0.0-preview2 PS C:\Users\hsbt\Downloads\ruby-4.0.0-preview2> cmd /k "C:\Program Files (x86)\Microsoft Visual Studio\18\BuildTools\VC\Auxiliary\Build\vcvars64.bat" hsbt@LAPLACE C:\Users\hsbt\Downloads\ruby-4.0.0-preview2>type revision.h #define RUBY_REVISION "4fa6e9938c" #define RUBY_FULL_REVISION "4fa6e9938cfb9458abd876ad4219a6648bfe1c96" #define RUBY_RELEASE_YEAR 2025 #define RUBY_RELEASE_MONTH 11 #define RUBY_RELEASE_DAY 17 hsbt@LAPLACE C:\Users\hsbt\Downloads\ruby-4.0.0-preview2>nmake up hsbt@LAPLACE C:\Users\hsbt\Downloads\ruby-4.0.0-preview2>win32\configure.bat Creating verconf.mk type 'nmake' to make ruby. hsbt@LAPLACE C:\Users\hsbt\Downloads\ruby-4.0.0-preview2>nmake up Microsoft(R) Program Maintenance Utility Version 14.50.35717.0 Copyright (C) Microsoft Corporation. All rights reserved. Downloading bundled gem files... revision.h updated Downloading bundled gem files... (snip) Extracting bundled gem files... hsbt@LAPLACE C:\Users\hsbt\Downloads\ruby-4.0.0-preview2>type revision.h #define RUBY_RELEASE_YEAR 2025 #define RUBY_RELEASE_MONTH 11 #define RUBY_RELEASE_DAY 19 ``` `RUBY_REVISION` and `RUBY_FULL_REVISION` is lost now. This caused the issue at release time of 4.0.0-preview2. We added the workaround at https://github.com/ruby/actions/commit/1561918fc1c929ee9ac4c2dd91af7870024a… -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122303] [Ruby Bug#21375] Set[] does not call #initialize
by Ethan (Ethan -) 18 Nov '25

18 Nov '25

Issue #21375 has been reported by Ethan (Ethan -). ---------------------------------------- Bug #21375: Set[] does not call #initialize https://bugs.ruby-lang.org/issues/21375 * Author: Ethan (Ethan -) * Status: Open * ruby -v: ruby 3.5.0dev (2025-05-26T17:42:35Z master 909a0daab6) +PRISM [x86_64-darwin22] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I have a subclass of Set that overrides #initialize. Following #21216, .new does call #initialize but .[] does not. ```ruby class MySet < Set def initialize(enum = nil) compare_by_identity super end end MySet.new.compare_by_identity? # => true MySet[].compare_by_identity? # => false ``` -- https://bugs.ruby-lang.org/

6 10

[ruby-core:123833] [Ruby Bug#21693] Allow calling any callable object as a method
by cheba (Alexander Mankuta) 18 Nov '25

18 Nov '25

Issue #21693 has been reported by cheba (Alexander Mankuta). ---------------------------------------- Bug #21693: Allow calling any callable object as a method https://bugs.ruby-lang.org/issues/21693 * Author: cheba (Alexander Mankuta) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Callable objects are popular in Ruby. A very common pattern of Service objects with a single public `call` method can be found in many Rails apps, too. I propose to extend syntax so that adding `()` to any object that has a `call` method to work as a method invocation. Example: ```ruby class Greeter def call(name) puts "Hello, #{name}!" end end hello = Greeter.new hello("World") # => Hello, World! ``` We have a `[]` method in `Proc` that achieves similar effect but it doesn't look like a method call. There's also a dotted syntax `hello.("World")` but it also looks a little awkward and the dot is easy to forget. It's probably a bit late for Ruby 4, but I though it's a good opportunity to introduce a potentially big change. -- https://bugs.ruby-lang.org/

3 2