February 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:117027] [Ruby master Bug#20319] Singleton class is being frozen lazily in some cases
by andrykonchin (Andrew Konchin) 24 Feb '26

24 Feb '26

Issue #20319 has been reported by andrykonchin (Andrew Konchin). ---------------------------------------- Bug #20319: Singleton class is being frozen lazily in some cases https://bugs.ruby-lang.org/issues/20319 * Author: andrykonchin (Andrew Konchin) * Status: Open * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I've noticed suspicious behaviour (it doesn't affect anything in practice for me though) when an object becomes frozen only its own singleton class becomes frozen immediately. A singleton class of the immediate singleton class becomes frozen lazily after `#singleton_class` method call: ```ruby o = Object.new klass = o.singleton_class.singleton_class o.freeze puts klass.frozen? # false <== here we expect true puts o.singleton_class.singleton_class.frozen? # true puts klass.frozen? # true ``` I would expect all created singleton classes in an object singleton classes chain to become frozen immediately. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:124869] [Ruby Feature#21923] DTrace USDT probe Ruby method arguments and return value
by jacobcarlborg (Jacob Carlborg) 23 Feb '26

23 Feb '26

Issue #21923 has been reported by jacobcarlborg (Jacob Carlborg). ---------------------------------------- Feature #21923: DTrace USDT probe Ruby method arguments and return value https://bugs.ruby-lang.org/issues/21923 * Author: jacobcarlborg (Jacob Carlborg) * Status: Open ---------------------------------------- I'm interested in improving the DTrace USDT probes in Ruby. I would like to expose the Ruby method arguments and return value to the DTrace probes `(c)method-entry` and `(c)method-return`. This would be done by adding a fifth argument to the DTrace probes. For `method-entry` this would be the Ruby arguments the Ruby method is called with and for `method-return` it would be the Ruby return value the Ruby method returned. My idea is to serialize the arguments as a JSON array and pass that as a C string, containing the JSON data, to the USDT probes. On the DTrace side, there's a `json` function available that can be used to extract parts of the JSON structure using a simple query string, example: `json(copyinstr(arg4), "success.foo.bar[1].baz")`. Because the serialization can fail, the top level JSON member would be `success` or `error` indicating if the serialization was successful or not. Using JSON to pass data to a DTrace USDT probe has precedence in the form of a Rust crate [1], created by one of the original DTrace authors, that uses the same approach. I have a proof of concept implementing this. I would like to get some feedback on how to best implement this. I think the main challenge is how to implement this without any side effects. Ruby already has support for serializing to JSON, but that is implemented in a separate gem, using a C extension. The challenges I see are: * There shouldn't be any side effects when enabling DTrace probes, therefore directly using the gem is not a good alternative. It needs to load a dynamic library and new constants will become available to the Ruby code, if this gem is used. * The JSON serialization for DTrace needs to live in the Ruby VM and not in a separate gem. The question is then: should the JSON serialization for the gem and the DTrace probes be shared? Alternatively there could be an implementation of JSON serialization, for the gem, and a DTrace probe argument serialization, that happens to use JSON, but would be an implementation detail. * If the JSON serialization should be shared between DTrace probes and the gem, is there a mechanism to share code between the Ruby VM and a gem without publicly exposing it, i.e. to C extensions? Or would there need to be an official JSON API that other C extensions could use? * The current JSON implementation relies on exceptions. For DTrace, it would be better not to rely on exceptions. But I guess it would be possible to catch all exceptions. * The current JSON implementation will, except for the `JSON` class, expose some additional constants which should not happen when using DTrace. This will introduce side effects. This should be possible to handle by slightly modifying the implementation. * The current JSON serialization supports customizing the serialization by implementing the `to_json`/`as_json` methods. If serializing DTrace arguments with support for the `to_json`/`as_json` methods, the advantage is that this is already implemented by some third-party libraries. The disadvantage is that it could cause side effects. * When DTrace probes are enabled and serializing the DTrace probe arguments and some Ruby methods are called, it would be best if those weren't traced. Can a global variable be used to check if the Ruby VM already is currently serializing DTrace probe arguments? Or is an atomic or thread-local variable necessary? Or is there a better alternative to do this? [1] https://github.com/oxidecomputer/usdt -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124868] [Ruby Feature#19107] Allow trailing comma in method signature
by Earlopain (Earlopain _) 23 Feb '26

23 Feb '26

Issue #19107 has been updated by Earlopain (Earlopain _). > What about the lambda arguments? @nobu it's unclear to me so I didn't change them. I added https://bugs.ruby-lang.org/issues/21875 to the next dev meeting. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116524 * Author: byroot (Jean Boussier) * Status: Closed * Assignee: core ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124867] [Ruby Feature#19107] Allow trailing comma in method signature
by nobu (Nobuyoshi Nakada) 23 Feb '26

23 Feb '26

Issue #19107 has been updated by nobu (Nobuyoshi Nakada). Assignee changed from prism to core What about the lambda arguments? commit:731b6092e9268af960bf0f060e37504f4deb7380 seems not to allow `->(a,) {}`. ---------------------------------------- Feature #19107: Allow trailing comma in method signature https://bugs.ruby-lang.org/issues/19107#change-116523 * Author: byroot (Jean Boussier) * Status: Closed * Assignee: core ---------------------------------------- A popular style for multiline arrays, hashes or method calls, is to use trailing commas: ```ruby array = [ 1, 2, 3, ] hash = { foo: 1, bar: 2, baz: 3, } Some.method( 1, 2, foo: 3, ) ``` The main reason to do this is to avoid unnecessary noise when adding one extra element: ```diff diff --git a/foo.rb b/foo.rb index b2689a7e4f..ddb7dc3552 100644 --- a/foo.rb +++ b/foo.rb @@ -1,4 +1,5 @@ Foo.bar( foo: 1, - bar: 2 + bar: 2, + baz: 3 ) ``` However, this pattern doesn't work with method declarations: ```ruby def foo(bar:,) # syntax error, unexpected ')' ``` ### Proposal For consistency and convenience I propose to allow trailing commas in method declarations. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124854] [Ruby Bug#21919] `libruby-static.a` links to wrong `Init_enc`
by reitermarkus (Markus Reiter) 22 Feb '26

22 Feb '26

Issue #21919 has been reported by reitermarkus (Markus Reiter). ---------------------------------------- Bug #21919: `libruby-static.a` links to wrong `Init_enc` https://bugs.ruby-lang.org/issues/21919 * Author: reitermarkus (Markus Reiter) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin20] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When building Ruby with `--with-static-linked-ext`, `libruby-static.a` links the `Init_enc` function from `dmyenc.c` instead of `enc/encinit.c.erb`, resulting in `uninitialized constant Encoding::UTF_8` error, among other things. There seems to be a discrepancy between `INITOBJS` (https://github.com/ruby/ruby/blob/e730ac41be4d427f06540e0f67fa16bbdced4789/…) and `ENCOBJS`/`EXTOBJS` (https://github.com/ruby/ruby/blob/e730ac41be4d427f06540e0f67fa16bbdced4789/…) Currently, the only workaround I found is to manually link `enc/libenc.a` and `enc/libtrans.a` to the final binary. Originally reported here: https://github.com/matsadler/magnus/issues/169 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124861] [Ruby Feature#17056] Array#index: Allow specifying the position to start search as in String#index
by Earlopain (Earlopain _) 21 Feb '26

21 Feb '26

Issue #17056 has been updated by Earlopain (Earlopain _). I often use the offset parameter from `String#byteindex` and was a bit surprised there is not yet something for arrays. It's a bit unfortunate with the ambiguity between block/noblock usage but a keyword argument `offset` seems like a perfectly fine solution for that. ---------------------------------------- Feature #17056: Array#index: Allow specifying the position to start search as in String#index https://bugs.ruby-lang.org/issues/17056#change-116515 * Author: TylerRick (Tyler Rick) * Status: Open ---------------------------------------- I have a use case of finding the first matching line within a given section in a file. After finding the line number of the start of the section, I want to find the first match after that line. My workaround for now is to use `with_index`: ```ruby lines = pathname.read.lines section_start_line = lines.index {|line| line.start_with?(/#* #{section_name}/) } lines.index.with_index {|line, i| i > section_start_line && line.include?(sought) } ``` I'd like to do it in a more concise way using a feature of `Array#index` that I propose here, which is analogous to `String#index`. If the second parameter of `String#index` is present, it specifies the position in the string to begin the search: ```ruby 'abcabc'.index('a') # => 0 'abcabc'.index('a',2) # => 3 ``` I would expect to also be able to do: ```ruby 'abcabc'.chars.index('a') # => 0 'abcabc'.chars.index('a', 2) ``` Using such feature, I would be able to do: ```ruby lines.index(sought, section_start_line) ``` This would give Ruby better parity with other programming languages like Python: ```python >>> list('abcabc') ['a', 'b', 'c', 'a', 'b', 'c'] >>> list('abcabc').index('a') 0 >>> list('abcabc').index('a', 2) 3 ``` ## End index We can further think of an optional parameter to specify the position to end the search. The following languages allow specifying both start and end indexes: - [Python](https://docs.python.org/3/tutorial/datastructures.html) - [C#](https://docs.microsoft.com/en-us/dotnet/api/system.array.indexof?view=n… Ruby's `String#index` does not have one, so we could make a separate proposal to add `end` to both methods at the same time. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124855] [Ruby Bug#21920] LIBRUBYARG_SHARED contains -lgmp and other libraries for static linking
by larskanis (Lars Kanis) 21 Feb '26

21 Feb '26

Issue #21920 has been reported by larskanis (Lars Kanis). ---------------------------------------- Bug #21920: LIBRUBYARG_SHARED contains -lgmp and other libraries for static linking https://bugs.ruby-lang.org/issues/21920 * Author: larskanis (Lars Kanis) * Status: Open * ruby -v: ruby 4.1.0dev (2026-02-21 master e730ac41be) +PRISM [aarch64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- That recent commit introduced `MAINLIBS` into `LIBRUBYARG_SHARED`: https://github.com/ruby/ruby/commit/d256629bf9e194838d1837be74dcc0b8ff0bcfd6 Before that commit: ``` CONFIG["LIBRUBYARG_SHARED"] = "-l$(RUBY_SO_NAME)" CONFIG["LIBRUBYARG_STATIC"] = "-l$(RUBY_SO_NAME)-static $(MAINLIBS)" RbConfig::CONFIG["LIBRUBYARG_SHARED"] # => "-laarch64-ucrt-ruby410" ``` After that commit: ``` CONFIG["LIBRUBYARG_SHARED"] = "-l$(RUBY_SO_NAME) $(MAINLIBS)" CONFIG["LIBRUBYARG_STATIC"] = "-l$(RUBY_SO_NAME)-static $(MAINLIBS)" RbConfig::CONFIG["LIBRUBYARG_SHARED"] # => "-laarch64-ucrt-ruby410 -lgmp -lshell32 -lws2_32 -liphlpapi -limagehlp -lshlwapi -lbcrypt" ``` To my understanding `MAINLIBS` are only for static linking and these libraries are not necessary for shared linking. This breaks RubyInstaller for Windows, since all C extensions are linked with `LIBRUBYARG_SHARED` and the RubyInstaller distribution ships `libgmp-10.dll` only but not related the `libgmp.a` file. The same happens on x86_64. It is probably an issue on other operating systems as well. A CI failure log is here: https://github.com/oneclick/rubyinstaller2/actions/runs/22238372563/job/643… -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124646] [Ruby Bug#21855] Bundle `win32-registry` or implement it without `fiddle`
by Earlopain (Earlopain _) 20 Feb '26

20 Feb '26

Issue #21855 has been reported by Earlopain (Earlopain _). ---------------------------------------- Bug #21855: Bundle `win32-registry` or implement it without `fiddle` https://bugs.ruby-lang.org/issues/21855 * Author: Earlopain (Earlopain _) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- `win32-registry` (a default gem), is currently implemented via `fiddle` (a bundled gem). This makes it impossible to use under bundler without adding `fiddle` to the gemfile. In the past it has lead to issues like https://bugs.ruby-lang.org/issues/21645. It was solved by simply not using `win32-registry` anymore in `resolv` and implementing it via C (https://github.com/ruby/resolv/pull/110) although the overarching issue is still present. There is also a report for this for rubygems https://github.com/ruby/rubygems/issues/9277. This should be solved by updating the vendored `resolv` version I think. Still, the dependecy relation between `win32-registry` and `fiddle` is pretty incompatible. A default gem can't depend on a bundled gem without breaking dependency resolution. To solve this it would have to be implemented without using `fiddle`, similar to how `resolv` did it. But now that `resolv` doesn't use `win32-registry`, I don't think anything in ruby uses it anymore. So moving it to a bundled gem could also be a solution without rewriting the whole thing. Here is an issue about this in the `win32-registry` repo: https://github.com/ruby/win32-registry/issues/11 -- https://bugs.ruby-lang.org/

3 5

[ruby-core:124845] [Ruby Feature#18035] Introduce general model/semantic for immutability.
by Eregon (Benoit Daloze) 17 Feb '26

17 Feb '26

Issue #18035 has been updated by Eregon (Benoit Daloze). @ioquatix I think `deep_freeze` would be a clear solution for that, so probably best to add your comments/support to #21665 and potentially also add it to the dev meeting agenda. ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-116498 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124841] [Ruby Feature#18035] Introduce general model/semantic for immutability.
by ioquatix (Samuel Williams) 16 Feb '26

16 Feb '26

Issue #18035 has been updated by ioquatix (Samuel Williams). Another example where immutability as a concept is useful - configurations that span across fibers and threads: https://github.com/ruby-i18n/i18n/issues/723 In general, it seems like `Fiber[]` for immutable values is a good idea. ---------------------------------------- Feature #18035: Introduce general model/semantic for immutability. https://bugs.ruby-lang.org/issues/18035#change-116462 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- It would be good to establish some rules around mutability, immutability, frozen, and deep frozen in Ruby. I see time and time again, incorrect assumptions about how this works in production code. Constants that aren't really constant, people using `#freeze` incorrectly, etc. I don't have any particular preference but: - We should establish consistent patterns where possible, e.g. - Objects created by `new` are mutable. - Objects created by literal are immutable. We have problems with how `freeze` works on composite data types, e.g. `Hash#freeze` does not impact children keys/values, same for Array. Do we need to introduce `freeze(true)` or `#deep_freeze` or some other method? Because of this, frozen does not necessarily correspond to immutable. This is an issue which causes real world problems. I also propose to codify this where possible, in terms of "this class of object is immutable" should be enforced by the language/runtime, e.g. ```ruby module Immutable def new(...) super.freeze end end class MyImmutableObject extend Immutable def initialize(x) @x = x end def freeze return self if frozen? @x.freeze super end end o = MyImmutableObject.new([1, 2, 3]) puts o.frozen? ``` Finally, this area has an impact to thread and fiber safe programming, so it is becoming more relevant and I believe that the current approach which is rather adhoc is insufficient. I know that it's non-trivial to retrofit existing code, but maybe it can be done via magic comment, etc, which we already did for frozen string literals. Proposed PR: https://github.com/ruby/ruby/pull/4879 -- https://bugs.ruby-lang.org/

1 0