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

[ruby-core:124419] [Ruby Bug#21827] Deprecating Ripper
by Eregon (Benoit Daloze) 03 Mar '26

03 Mar '26

Issue #21827 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #21827: Deprecating Ripper https://bugs.ruby-lang.org/issues/21827 * Author: Eregon (Benoit Daloze) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I think it is time to consider deprecating `Ripper`. [Matz has agreed that going forward the official parser API for Ruby will be the Prism API](https://railsatscale.com/2024-04-16-prism-in-2024/) so it's clear the official Ruby parsing API is the Prism API. `Ripper` while being currently supported on CRuby, JRuby and TruffleRuby (partially) has a significant maintenance overhead. For CRuby, it roughly doubles the number of lines in `parse.y` and adds lots of `#ifdef RIPPER`/`#ifndef RIPPER` which makes it really hard to follow. For JRuby it's many thousands of lines of code to maintain just for that: https://github.com/jruby/jruby/tree/master/core/src/main/java/org/jruby/ext… For TruffleRuby, `ripper` is by far the most difficult C extension to support as it relies on many internal functions. When an internal function is used by ripper is missing it kills the entire process. On every update of `RUBY_VERSION` in TruffleRuby, the biggest amount of time is spent dealing with Ripper, which feels as a result like a major hack. It could be possible to implement Ripper based on Prism, in fact there is [some support for that](https://github.com/ruby/prism/blob/main/docs/ripper_translation.md), but the fact the Ripper API is rather unstable means it's hard to be compatible, and currently the translation layer [relies on original ripper for some things](https://github.com/ruby/prism/blob/e0e5e68acbed98a6b4e4e77b9b52b448…. It's also worth noting that [`Ripper.sexp` is 2.75x slower than `Prism.parse`](https://eregon.me/blog/2024/10/27/benchmarking-ruby-parsers.html#parsing-and-not-walking), while providing a much worse API (widely recognized as such, e.g. `Ripper.sexp("def m = 42")` vs `Prism.parse("def m = 42")`, lots of `nil` with unclear meaning in `Ripper`). So from a new code perspective there seems to be very little value to use `Ripper`. `Ripper` has lexing via `Ripper.lex`, which can be replaced by `Prism::lex_compat`. I think we should start to deprecate `Ripper`. The advantages of deprecating it are: * Make it clear that this API should not be used in new code * Encourage the usages to migrate to the Prism API, which is stable, officially supported, designed with many people to be usable and convenient for every parsing/tooling usage, etc. * Improve portability of Ruby code between Ruby implementations (given Ripper is not fully compatible between Ruby implementations) I propose to deprecate Ripper in 4.1. I'm not sure when it would be appropriate to remove it given it's a more established API, maybe in 4.2, 4.3? -- https://bugs.ruby-lang.org/

5 8

[ruby-core:124891] [Ruby Misc#21928] Prism backport handling
by Earlopain (Earlopain _) 03 Mar '26

03 Mar '26

Issue #21928 has been reported by Earlopain (Earlopain _). ---------------------------------------- Misc #21928: Prism backport handling https://bugs.ruby-lang.org/issues/21928 * Author: Earlopain (Earlopain _) * Status: Open * Assignee: prism ---------------------------------------- https://bugs.ruby-lang.org/issues/21927 got marked for backport for 4.0 and 3.4. It's a trivial fix but since prism is a gem, ruby should contain a released version of prism only. 3.4 in particular currently contains prism 1.5.2. Backporting to that version would require at least two changes in `ruby/ruby` because of changes in prism itself. So it is not as easy as just `tool/sync_default_gems`. Currently the practise has been to just backport the lastest prism version but personally I don't think that is sustainable. At best it causes more work than necessary and at worst you get fresh new bugs in what is supposed to be a stable ruby release. https://github.com/ruby/prism/pull/3231 is a good example of something that should not be backported to all maintained ruby versions when it gets merged. I propose to maintain stable branches for prism. Branch maintainers can simply cherry-pick what they think should be backported and prism takes care of releasing the appropriate versions, branched from the version that the stable ruby version originally shipped with. As far as I'm aware, that's also the strategy other gems go with. It happens less frequent now that many gems are no longer standard gems but openssl for example has branches for this purpose https://github.com/ruby/openssl/branches. I'm not sure how it handles versions, some gems I see do `1.2.3.4` which doesn't exactly follow semver, but it should possible to do it by following semver. What do you think @kddnewton? I know that so far you've wanted to do the latest stable version but I think prism is too intertwined with ruby itself for the current approach. Especially now that there are two stable branches that ship with prism it doesn't get easier. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123894] [Ruby Bug#21709] Inconsistent encoding by Regexp.escape
by thyresias (Thierry Lambert) 26 Feb '26

26 Feb '26

Issue #21709 has been reported by thyresias (Thierry Lambert). ---------------------------------------- Bug #21709: Inconsistent encoding by Regexp.escape https://bugs.ruby-lang.org/issues/21709 * Author: thyresias (Thierry Lambert) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [x64-mingw-ucrt] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- ```ruby %w(foo être).each do |s| puts "string: #{s.inspect} -> #{s.encoding}" puts "escaped: #{Regexp.escape(s).inspect} -> #{Regexp.escape(s).encoding}" end ``` Output: ``` string: "foo" -> UTF-8 escaped: "foo" -> US-ASCII string: "être" -> UTF-8 escaped: "être" -> UTF-8 ``` The result should always match the encoding of the argument. -- https://bugs.ruby-lang.org/

5 13

[ruby-core:124878] [Ruby Feature#4477] Kernel:exec and backtick (`) don't work for certain system commands
by schneems (Richard Schneeman) 24 Feb '26

24 Feb '26

Issue #4477 has been updated by schneems (Richard Schneeman). Just found out about this behavior today when this code ``` out = `command -v ruby` ``` Works on my mac but not on linux (github actions) with an error `Errno::ENOENT: No such file or directory - command`. That is because on my mac `command` is ALSO on the PATH, but on linux it is not. I could fix it by adding a redirect ``` out = `command -v ruby 2>/dev/null` ``` Which triggers the shell behavior. I find it surprising that exec mentions this behavior https://www.rubydoc.info/stdlib/core/Kernel:exec but backticks https://ruby-doc.org/3.4.1/Kernel.html#method-i-60 doesn't. ---------------------------------------- Feature #4477: Kernel:exec and backtick (`) don't work for certain system commands https://bugs.ruby-lang.org/issues/4477#change-116537 * Author: JWuttke (Joachim Wuttke) * Status: Closed * Assignee: akr (Akira Tanaka) ---------------------------------------- From documentation and common sense, I would expect that Kernel:exec and backtick (`) work for _all_ kind of system commands. This is currently not the case. ~$ cat test1 echo success ~$ cat test2 #!/bin/sh echo success ~$ chmod a+x test? ~$ ruby1.8 -e 'p `test1`' -e:1: command not found: test1 "" ~$ ruby1.9 -e 'p `test1`' -e:1:in ``': Exec format error - test1 (Errno::ENOEXEC) from -e:1:in `<main>' ~$ ruby1.8 -e 'p `test2`' "success\n" ~$ ruby1.9 -e 'p `test2`' "success\n" This problem has been reported before (#3856: strange Kernel#exec behavior with bash's source command). As a workaround, it has been suggested to append a semikolon to the system command: ~$ ruby1.8 -e 'p `test1;`' "success\n" ~$ ruby1.9 -e 'p `test1;`' "success\n" The report #3856 has been closed with the decision "not a bug". This I cannot accept. For many years, I got used to run system commands through `<cmd>`. When it failed, I spent painfully long time to search for a bug in my Ruby code and in the system command before I realized the problem was due to an unexpected restriction of Ruby's exec/backtick. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124497] [Ruby Feature#21835] Unbundle bunled gems like net-ftp
by hsbt (Hiroshi SHIBATA) 24 Feb '26

24 Feb '26

Issue #21835 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21835: Unbundle bunled gems like net-ftp https://bugs.ruby-lang.org/issues/21835 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- I would like to unundle the following bundled gems: * net-ftp * net-pop * prime The main purpose of bundled gems is to ensure their functionality by running tests with ruby head every time. However, the above gems for older protocols or purposes should be handled the same as other regular gems. -- https://bugs.ruby-lang.org/

1 3

[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