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:124885] [Ruby Bug#21925] Prism misparses standalone "in" pattern matching in "case/in"
by knu (Akinori MUSHA) 02 Mar '26

02 Mar '26

Issue #21925 has been reported by knu (Akinori MUSHA). ---------------------------------------- Bug #21925: Prism misparses standalone "in" pattern matching in "case/in" https://bugs.ruby-lang.org/issues/21925 * Author: knu (Akinori MUSHA) * Status: Open * Target version: 4.1 * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Prism misparses standalone `in` pattern matching in `case/in` when the left-hand side is a method call with a dot receiver ## Summary When a standalone `expr in pattern` one-line pattern match appears inside a `case/in` branch, and `expr` is a method call with a dot receiver (for example, `obj.method`), Prism incorrectly parses `in pattern` as a new branch of the outer `case/in` instead of treating it as a `MatchPredicateNode`. The parse.y parser handles this case correctly. ## Reproduction ``` $ ruby -v ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [arm64-darwin23] ``` It also reproduces on Ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [arm64-darwin25]. ### Minimal script ```ruby x = "x" case x in Integer nil in String p :before x.itself in String p :after end ``` ### Command output ``` $ ruby -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before $ ruby --parser=parse.y -e ' x = "x" case x in Integer nil in String p :before x.itself in String p :after end ' :before :after ``` ### Expected behavior (parse.y) Both `:before` and `:after` are printed. `x.itself in String` is parsed as a standalone pattern match (predicate) inside the `in String` branch. ### Actual behavior (Prism) Only `:before` is printed; `p :after` is never executed. ## Analysis Prism splits `x.itself in String` at the `in` keyword, treating `x.itself` as the last statement of the `in String` branch and `in String` as a third branch of the outer `case/in`. The following script shows how each parser interprets the `case/in` branches: ```ruby code = <<~RUBY x = "x" case x in Integer nil in String x.itself in String p :after end RUBY # Prism require "prism" ast = Prism.parse(code).value.statements.body[1] puts "Prism: conditions: #{ast.conditions.length}" ast.conditions.each_with_index do |c, i| pat = c.pattern name = pat.respond_to?(:name) ? pat.name : pat.class stmts = c.statements&.body&.map { |s| s.class.name.split("::").last } || [] puts " in[#{i}]: pattern=#{name}, body=#{stmts}" end # parse.y (Ripper) require "ripper" sexp = Ripper.sexp(code) case_node = sexp[1][1] def count_in_branches(node) return [] unless node.is_a?(Array) && node[0] == :in pattern_node = node[1] body = node[2] || [] name = pattern_node.is_a?(Array) && pattern_node[1].is_a?(Array) ? pattern_node[1][1] : pattern_node[1] stmts = body.map { |s| s[0].to_s } [{ pattern: name, body: stmts }] + count_in_branches(node[3]) end branches = count_in_branches(case_node[2]) puts "\nparse.y (Ripper): conditions: #{branches.length}" branches.each_with_index do |b, i| puts " in[#{i}]: pattern=#{b[:pattern]}, body=#{b[:body]}" end ``` Output (run with `ruby --parser=parse.y` so Ripper uses parse.y): ``` Prism: conditions: 3 in[0]: pattern=Integer, body=["NilNode"] in[1]: pattern=String, body=["CallNode"] in[2]: pattern=String, body=["CallNode"] parse.y (Ripper): conditions: 2 in[0]: pattern=Integer, body=["var_ref"] in[1]: pattern=String, body=["case", "command"] ``` Prism reports 3 branches, while parse.y reports 2. In the parse.y result, `in[1]` correctly contains both the inner expression (`x.itself in String` parsed as a standalone pattern match) and the `command` (`p :after`). In the Prism result, `x.itself` becomes the sole body of `in[1]`, and `in String` is misinterpreted as a new `in[2]` branch of the outer `case`. ## Consideration From experimentation, the issue appears to be triggered only when all of the following are true: 1. The outer `case/in` has at least two `in` branches before the affected branch. 2. The standalone `in` expression uses a dot-receiver method call as its left-hand side, such as `obj.method in Pattern`. Conditions where this behavior is not observed: - If the expression is a receiver-less call, such as `f(x) in Pattern`, the parser keeps it as a standalone pattern match. - If the receiver expression is parenthesized, such as `(obj.method) in Pattern`, the parser keeps it as a standalone pattern match. - If you assign first, such as `y = obj.method; y in Pattern`, the parser keeps it as a standalone pattern match. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:124892] [Ruby Feature#21929] Add configure script options for instrumenting Rust builds
by jprokop (Jarek Prokop) 27 Feb '26

27 Feb '26

Issue #21929 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Feature #21929: Add configure script options for instrumenting Rust builds https://bugs.ruby-lang.org/issues/21929 * Author: jprokop (Jarek Prokop) * Status: Open ---------------------------------------- Ruby at this moment optionally includes Rust bits. Right now this touches mostly YJIT and ZJIT. Rust is a compiled language with various compile flags at various stages and approaches. My ask is to provide a way to instrument compilation similarly as with C at the moment so that packagers and distributions can be fully and easily compliant with their guidelines on compilation flags. Currently, for production build of Ruby, `rustc` tool is used, which is instrumented differently from `cargo` in debug builds. In my PR motivated by the described goal: https://github.com/ruby/ruby/pull/15695 I have focused on providing `rustc` with our distribution flags, during the PR it was mentioned that there are flags related to security https://github.com/ruby/ruby/pull/15695#discussion_r2663651764 that should be present even when providing distribution flags. This is not too different from C, as there are also security flags, such as configure script enabling the arm64's BTI and PAC when possible. `rustc` of version 1.92, at the time of the PR uses the last mention of a flag. Ideally `rustc` would know `RUSTFLAGS`, but as far as I can tell, the enviroment variable only affects `cargo`. In Fedora the current guidance recommends using `%build_rustflags` https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_compiler_f… which expands to `-Copt-level=3 -Cdebuginfo=2 -Ccodegen-units=1 -Cstrip=none -Cforce-frame-pointers=yes --cap-lints=warn` The best result is each part of Rust in Ruby would receive the flags defined during `configure` time. In cases where complication flags should conflict, in Fedora distribution flags take precedence: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_building_w… -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124888] [Ruby Bug#21927] Prism: misleading error message for forwarding in lambda argument
by nobu (Nobuyoshi Nakada) 27 Feb '26

27 Feb '26

Issue #21927 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21927: Prism: misleading error message for forwarding in lambda argument https://bugs.ruby-lang.org/issues/21927 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: prism * ruby -v: d256629bf9 * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Even in a forwarding method: ```console $ ruby --parser=prism -e 'def m(...) ->(...){}; end' -e: -e:1: syntax error found (SyntaxError) > 1 | def m(...) ->(...){}; end | ^~~ unexpected ... when the parent method is not forwarding ``` This message is proper for method arguments: ```console $ ruby --parser=prism -e 'def m() p(...); end' -e: -e:1: syntax error found (SyntaxError) > 1 | def m() p(...); end | ^~~ unexpected ... when the parent method is not forwarding ``` The message from parse.y is different; "unexpected ... in lambda argument": ```console $ ruby --parser=parse.y -e 'def m(...) ->(...){}; end' -e:1: unexpected ... in lambda argument def m(...) ->(...){}; end ruby: compile error (SyntaxError) ``` -- https://bugs.ruby-lang.org/

2 1

[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:124877] [Ruby Misc#21924] Register a Maven artifact for JVM-related libraries
by headius (Charles Nutter) 25 Feb '26

25 Feb '26

Issue #21924 has been reported by headius (Charles Nutter). ---------------------------------------- Misc #21924: Register a Maven artifact for JVM-related libraries https://bugs.ruby-lang.org/issues/21924 * Author: headius (Charles Nutter) * Status: Open ---------------------------------------- For the Prism project, I am working toward having published artifacts for JVM users (like JRuby or TruffleRuby). Publishing these packages will make it much easier for us to support Prism in JRuby, both as our interal Ruby parser and as an installable gem. We do not copy sources into our repository, and *must* be able to point a release artifact that can be tracked through supply chain tooling etc. In order to publish artifacts, we need to register the `org.ruby-lang` namespace with Sonatype, maintainers of Maven Central (the primary source of JVM-based software packages). The process is detailed here: https://central.sonatype.org/register/namespace/ The simple description of the process follows: 1. Register an account on Sonatype. I already have one for JRuby and other JVM projects. 2. Register the namespace. I have posted an initial request for the `org.ruby-lang` namespace. 3. Verify the namespace. This requires DNS help as described on the above page and in the screenshot below. 4. Publish artifacts to the namespace. The first artifact would be named something like `prism-ruby-parser`, so its "coordinates" would be `org.ruby-lang:prism-ruby-parser:0.0.1`. I need: * Someone who can update the DNS entry to include the key needed by Sonatype for verification. * A list of users who should potentially have push rights for this namespace. I don't expect anyone but JRuby committers and possibly TruffleRuby committers will be using this namespace. For the moment I will be publishing the artifacts I need under the `org.jruby` namespace, but because there's very little JRuby-specific logic in the core Prism JVM wrapper library, I would prefer to publish it under the `org.ruby-lang` domain. -- https://bugs.ruby-lang.org/

2 4

[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:124857] [Ruby Bug#21921] Hash inconsistent ==, >=, <= behavior
by cohen (Cohen Carlisle) 24 Feb '26

24 Feb '26

Issue #21921 has been reported by cohen (Cohen Carlisle). ---------------------------------------- Bug #21921: Hash inconsistent ==, >=, <= behavior https://bugs.ruby-lang.org/issues/21921 * Author: cohen (Cohen Carlisle) * Status: Open * ruby -v: ruby 4.0.1 (2026-01-13 revision e04267a14b) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hash seems to have very inconsistent behavior for `==`, `>=`, and `<=`. Given that below h1 == h2 is `false` and that they have the same number of keys, I would expect `<=` and `>=` to also be `false`. However, surprisingly `h1 <= h2` and `h2 >= h1` are `true`, while all other permutations are `false`. ``` h1 = {}.compare_by_identity.tap { _1["one"] = 1 } # => {"one" => 1} h2 = {"one" => 1} # => {"one" => 1} h1 == h2 # => false h2 == h1 # => false h1 >= h2 # => false h1 <= h2 # => true h2 >= h1 # => true h2 <= h1 # => false ``` -- https://bugs.ruby-lang.org/

4 6

[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