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

[ruby-core:125595] [Ruby Misc#22088] DevMeeting-2026-06-11
by mame (Yusuke Endoh) 10 Jun '26

10 Jun '26

Issue #22088 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #22088: DevMeeting-2026-06-11 https://bugs.ruby-lang.org/issues/22088 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/06/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 2026/06/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/

11 10

[ruby-core:125644] [Ruby Bug#22096] Freeing a mutex locked by a fiber inside fiber scheduler can crash
by luke-gru (Luke Gruber) 09 Jun '26

09 Jun '26

Issue #22096 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #22096: Freeing a mutex locked by a fiber inside fiber scheduler can crash https://bugs.ruby-lang.org/issues/22096 * Author: luke-gru (Luke Gruber) * Status: Open * Assignee: luke-gru (Luke Gruber) * Target version: 4.1 * Backport: 4.0: REQUIRED, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- While freeing a locked mutex, if there is a waiter for the mutex it could call `rb_fiber_scheduler_unblock` which calls into Ruby code. The function `rb_mutex_unlock_th` was a footgun because it was used during normal Ruby code and also during GC. The fix is to not call this function during GC and simply remove the mutex from `th->keeping_mutexes`. [PR](https://github.com/ruby/ruby/pull/17204) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125575] [Ruby Feature#22081] Core type definition migration from `ruby/rbs` to `ruby/ruby`
by soutaro (Soutaro Matsumoto) 09 Jun '26

09 Jun '26

Issue #22081 has been reported by soutaro (Soutaro Matsumoto). ---------------------------------------- Feature #22081: Core type definition migration from `ruby/rbs` to `ruby/ruby` https://bugs.ruby-lang.org/issues/22081 * Author: soutaro (Soutaro Matsumoto) * Status: Open * Assignee: soutaro (Soutaro Matsumoto) * Target version: 4.1 ---------------------------------------- Currently, the RBS type definitions for core libraries live in the `ruby/rbs` repository. When you change a core class or method in `ruby/ruby`, the corresponding RBS type definition often needs to be updated too — but that update requires a separate PR to `ruby/rbs`, so the work cannot be completed within `ruby/ruby` alone. This is painful for Ruby core committers and contributors. To address this problem, we will move the core library type definitions to `ruby/ruby` so that you can update the RBS type definitions within the same PR. We want to get this done in Ruby 4.1. **Question:** Do you have any concerns about migrating the RBS core type definitions to `ruby/ruby`? ## Current workflow The `test-bundled-gems` CI job in `ruby/ruby` runs the core type definition tests bundled with the rbs-gem. The tests actually call core methods and validate that the arguments and return values have the expected types using `is_a?`. When you change a core library in `ruby/ruby` in a way that requires a type definition update, the `test-bundled-gems` job fails and CI turns red. At that point, you have two options: 1. **Update the RBS type definitions** by submitting a separate PR to `ruby/rbs` 2. **Skip the failing tests** by adding the test name to the `rbs_skip_tests` file (in `ruby/ruby` repository) Either way, you are forced to take some action to get CI green again. Option 1 is actually very painful in practice. The type definitions bundled with the rbs-gem correspond to the released version of Ruby, not the in-development version. As a result, PRs to `ruby/rbs` for in-development APIs often end up modifying tests rather than type definitions — wasteful and frustrating work. Some examples: https://github.com/ruby/rbs/pull/2366 https://github.com/ruby/rbs/pull/2706 ## Updated workflow We can streamline the workflow by moving the core library RBS type definitions to `ruby/ruby` repository. - We will add a directory such as `sig` to `ruby/ruby` and store files like `string.rbs` there - Ruby's CI will run tests (`test-bundled-gems`) for the RBS type definitions in `ruby/ruby` repository. If your commit changes the core library methods/classes, please update the RBS files and tests too. - Ruby 4.1 will ship with the core type definitions, which will be installed with it. The rbs-gem will load the core library type definitions shipped with Ruby. With this workflow, when `test-bundled-gems` fails, you can fix the issue directly within your `ruby/ruby` work — without leaving the repository or coordinating a separate PR — which makes updating RBS much easier. *Note:* This workflow introduces a new step — *updating the RBS type definitions* — that wasn't previously required of Ruby committers. However, it replaces the existing workaround of skipping tests or coordinating a separate PR to `ruby/rbs` just to keep CI green. And unlike that workaround, updating the RBS definitions is itself a real improvement to Ruby. We believe this trade-off is acceptable. ## Implementation plan ### What we won't do 1. We will keep rbs-gem as a bundled gem. We won't make it a default gem, default library, or Ruby built-in. rbs-gem has a C extension, and changing from a bundled gem would require significantly more work for compilation. 2. We will keep the `ruby/rbs` repository for development of the library implementation. We want to release new versions of the gem more often than Ruby's release cycle. ### File layout in `ruby/ruby` repository - Type definitions will be stored under `sig/` (e.g., `sig/core/string.rbs`) - Type definition tests will be placed under `test/sig` - The bundled version of rbs-gem will be used to test against the `sig/` type definitions and `test/sig` tests Note that the directory names are tentative. Let me know if you have an idea what the names of the directories should be. ### Installation and distribution When Ruby is installed, the core and standard library RBS type definitions will be installed alongside it. The rbs-gem will reference these bundled definitions rather than maintaining its own copy. The RBS files will be installed under something like `"#{RbConfig::CONFIG["prefix"]}/sig"`, but the exact path is not decided yet. Suggestions are welcome! *Note:* We may also want an install-time option to skip installing the RBS type definitions, for example for minimal Ruby builds where they are not needed. #### Releasing new type definitions Currently, we can release a new version of rbs-gem to update the core type definition. After this migration, we need to wait for the next Ruby release to update type definition. I think this is okay, since the core type definition is pretty stable today. ### Testing RBS type definition tests will run as part of `make test-all` in `ruby/ruby`, rather than only through `test-bundled-gems`. This ensures type definitions are validated during the standard Ruby development workflow. Note that the RBS test suite currently takes 2–3 minutes in CI, so we need to decide which development tasks should include full testing. ### Other notes - Core RBS definitions contain documentation copied from RDoc, which needs to be updated before each release. For now, @soutaro plans to do this manually. - Ruby 4.0 and earlier releases do not include RBS type definitions, so the rbs-gem releases must continue to bundle them. @soutaro will copy the type definitions from `ruby/ruby` to `ruby/rbs` at each rbs-gem release. -- https://bugs.ruby-lang.org/

5 9

[ruby-core:125641] [Ruby Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by koic (Koichi ITO) 08 Jun '26

08 Jun '26

Issue #18915 has been updated by koic (Koichi ITO). I had an opportunity to discuss this with @matz and @shyouhei at Matsue RubyKaigi 12, held on June 6, 2026. Below is a summary of that discussion. - Leave the current `NotImplementedError` unchanged for now. - Introduce a new exception class intended for cases where a method is expected to be defined in a subclass. - The new class should inherit from `ScriptError` (not `RuntimeError`), following the same rationale as `SyntaxError` and `LoadError`. It represents a problem with the script itself rather than a runtime error. - `SubclassResponsibility` (or `AbstractMethodError`) is a candidate name for the new `ScriptError` subclass. Additional context reflecting my understanding of the discussion, together with some personal observations. Instead of introducing a new exception class, it would also be possible to consider a different mechanism that results in a `NoMethodError`. However, there have been repeated instances of `NotImplementedError` being used in ways that do not match its intended purpose. Furthermore, AI-generated code is also sometimes seen using `NotImplementedError` incorrectly in this manner. Since this misuse of `NotImplementedError` is already widespread, the introduction of `SubclassResponsibility` would provide a migration path for such cases. For cases where `NotImplementedError` is currently being used incorrectly, the migration path would be to replace it with `SubclassResponsibility`. For existing code that is using `NotImplementedError` correctly, no changes would be necessary and those usages would remain as they are. ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-117490 * Author: Quintasan (Michał Zając) * Status: Open ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- 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) 07 Jun '26

07 Jun '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/

4 3

[ruby-core:124885] [Ruby Bug#21925] Prism misparses standalone "in" pattern matching in "case/in"
by knu (Akinori MUSHA) 07 Jun '26

07 Jun '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/

5 5

[ruby-core:123731] [Ruby Bug#21674] Possible regression in return case in statement
by jandudulski (Jan Dudulski) 07 Jun '26

07 Jun '26

Issue #21674 has been reported by jandudulski (Jan Dudulski). ---------------------------------------- Bug #21674: Possible regression in return case in statement https://bugs.ruby-lang.org/issues/21674 * Author: jandudulski (Jan Dudulski) * Status: Open * ruby -v: 3.4.6 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Suddenly my code started failing in Ruby 3.4.6 and 3.4.7. Shortest code example: ``` ruby args = [:increased] context = Data.define(:event).new(:decreased) case args in [event] context.event in ^event end ``` In Ruby prior to 3.4.6 in returns `false` (as expected) but in 3.4.6 and 3.4.7 it returns `:decreased`. `context.event in ^event` still returns `false`. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:124474] [Ruby Bug#21831] Prism doesn't count underscores in the fraction part of rational float
by nobu (Nobuyoshi Nakada) 07 Jun '26

07 Jun '26

Issue #21831 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21831: Prism doesn't count underscores in the fraction part of rational float https://bugs.ruby-lang.org/issues/21831 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Good. ```console $ ruby3.3 -e 'p 0.1_2r.to_f' 0.12 $ ruby3.4 --parser=parse.y -e 'p 0.1_2r.to_f' 0.12 ``` Wrong. ```console $ ruby3.4 -e 'p 0.1_2r.to_f' 0.012 ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:125631] Invitation to RubyConf Community Day
by Ufuk Kayserilioglu 05 Jun '26

05 Jun '26

I am sending the message below on behalf of Rachael Wright-Munn <chaelcodes(a)gmail.com>, who is organizing the RubyConf 2026 Hack Spaces, and is CC'ed to this email. Please direct all future correspondence about the event to her. Thank you! --- Hello ruby-core! We’re reaching out to invite you to participate in Hack Spaces during RubyConf 2026, which is in Las Vegas, NV, from July 14th to 16th. Hack Spaces will take place on Day 2 of the conference (July 15th), during Community Day. Hack Spaces at RubyConf 2026 is a collaborative event dedicated to contributing to open source projects that power the Ruby ecosystem. It's an opportunity for maintainers to collaborate in person and onboard new contributors. You can learn more about this aspect of Community Day here. ( https://storage.ghost.io/c/17/0a/170a5cb5-5524-4ba0-93b6-f17fc9bacca6/conte… ) This year, we'd like to dedicate a space to working on the Ruby programming language. By creating space for cross-project, in-person collaboration between maintainers, we hope to support the open-source community and drive the next innovation in Ruby. We sincerely hope that you attend and find it valuable. We have a site dedicated to sharing information about the projects and their maintainers. We would love to feature any maintainers or contributors who are planning to attend. If you are interested in being featured on the site, please reply to this message with name, photo/avatar, job title, company name, and any socials. As a reminder, all Ruby Core members receive free tickets to RubyConf, please reach out to rubyconf(a)rubycentral.org for assistance in that regard. With appreciation, RubyConf 2026 Program Committee & Staff

1 0

[ruby-core:125083] [Ruby Misc#21960] Improve #backtrace to not confuse terminals
by svoop (Sven Schwyn) 05 Jun '26

05 Jun '26

Issue #21960 has been reported by svoop (Sven Schwyn). ---------------------------------------- Misc #21960: Improve #backtrace to not confuse terminals https://bugs.ruby-lang.org/issues/21960 * Author: svoop (Sven Schwyn) * Status: Open ---------------------------------------- The `#backtrace` of exceptions are currently printed like so: ``` /path/to/whatever.rb:8:in `/' /path/to/whatever.rb:8:in `show' (...) ``` Most terminals recognize `/path/to/whatever.rb:8` as a local file and make it clickable as "open in editor", however, some (e.g. Ghostty) include everything up to the next whitespace, in this case `/path/to/whatever.rb:8:in`. This is then used as an argument to `open` (on macOS) which will not work due to the `:in` part. There are two ways to improve this: ## Replace the colon with a space Given the existence of `#backtrace_locations` which is better suited for programmatically working with backtrace locations, it should not break things to slightly modify the `#backtrace` to look like this: ``` /path/to/whatever.rb:8 in `/' /path/to/whatever.rb:8 in `show' (...) ^^^ space instead of colon ``` ## Add OCS 8 sequences [OCS 8](https://github.com/Alhadis/OSC8-Adoption) are the `<a>` tag for terminal output. While many terminals support it, it might cause visual noise in logs and therefore would have to be an opt-in feature e.g. via a Ruby interpreter argument. -- https://bugs.ruby-lang.org/

8 17