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

[ruby-core:125624] [Ruby Feature#22093] Introduce `Process::ID` for process IDs returned by `Process.spawn` and `fork`
by nobu (Nobuyoshi Nakada) 11 Jun '26

11 Jun '26

Issue #22093 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22093: Introduce `Process::ID` for process IDs returned by `Process.spawn` and `fork` https://bugs.ruby-lang.org/issues/22093 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- Currently, process IDs returned by `Process.spawn` and `fork` are plain `Integer` objects. This works, but it makes common process-handling code slightly verbose and loses the opportunity to attach process-specific behavior to the returned value. For example: ```ruby pid = Process.spawn(...) _, status = Process.wait2(pid) if status.success? ... end ``` I propose introducing `Process::ID`, an Integer-like object representing a system process ID. `Process.spawn` and parent-side `Process.fork` would return `Process::ID`. `Process::ID` would provide convenience methods such as `#wait` and `#detach`. This allows process lifecycle code to be written more directly: ```ruby pid = Process.spawn(...) status = pid.wait if status.success? ... end ``` and, when the parent does not intend to wait explicitly: ```ruby pid = Process.spawn(...) pid.detach ``` ### Proposal Add `Process::ID`. `Process::ID` would: * represent a process ID * provide `#to_i` and `#to_int` * provide `#to_s` returning the decimal PID string * provide `#inspect`, like as `Process::Status` * provide `#pid` as a reader for the integer PID * provide `#wait`, returning `Process::Status` * provide `#detach`, returning `Process::Waiter` * support comparison with the underlying integer PID `Process.spawn` would return a `Process::ID` instead of an `Integer`. On platforms with `fork`, parent-side `fork` and `Process.fork` would return a `Process::ID`. The child side would keep the current behavior: `nil` for `fork` and `0` for `Process._fork`. `IO#pid` for `IO.popen` should also return the associated `Process::ID` when applicable. ### Rationale A process ID is currently represented by an `Integer`, but conceptually it is not just a number. It is a handle-like value used with process APIs such as `wait`, `waitpid`, `kill`, and `detach`. Providing a dedicated object makes common operations more discoverable and concise, while keeping compatibility through `#to_i`/`#to_int`. This is similar in spirit to `Process::Status`: process-related values can still expose primitive information, but the object itself can provide process-specific operations. `#wait` is useful when the parent wants to wait for the child and obtain its `Process::Status`: ```ruby pid = Process.spawn("ruby", "-e", "exit 0") pid.wait.success? #=> true ``` `#detach` is useful when the parent intentionally does not want to wait for the child directly, but still wants to avoid leaving a zombie process: ```ruby pid = Process.spawn("ruby", "-e", "sleep 1") waiter = pid.detach waiter.value #=> #<Process::Status: pid ... exit 0> ``` This is preferable to tying process cleanup to object finalization. A `dfree`/GC-based wait would make process reaping depend on GC timing and could unexpectedly consume the child status before explicit `Process.wait` code gets to it. `#detach` keeps the ownership transfer explicit. ### Compatibility This is a visible compatibility change because `Process.spawn(...).class` would become `Process::ID` instead of `Integer`. However, code that passes the PID to existing process APIs should continue to work because `Process::ID` provides `#to_int`. Potentially affected code is code that checks the exact class of the returned value, such as `pid.instance_of?(Integer)`, or uses type checks such as `Integer === pid`. Such code would need to treat the value as integer-like instead, for example by using `pid.to_i` when an actual `Integer` object is needed. For `Process._fork`, if it is overridden, `fork` should preserve the object returned by the overridden `_fork` on the parent side, as long as it is Integer-like. This keeps custom hooks compatible with code that returns PID wrapper objects. ### Examples ```ruby pid = Process.spawn("ruby", "-e", "exit 0") pid.class #=> Process::ID pid.to_i #=> 12345 pid.to_s #=> "12345" pid.wait #=> #<Process::Status: pid 12345 exit 0> ``` ```ruby pid = fork { exit! true } pid.class #=> Process::ID pid.wait.success? #=> true ``` ```ruby pid = Process.spawn("ruby", "-e", "sleep 1") thread = pid.detach #=> #<Process::Waiter:...> thread.value #=> #<Process::Status: pid ... exit 0> ``` ### Open questions * Should `Process::ID` include `Comparable`, or only define `<=>`? `<=>` is useful because PIDs have historically been `Integer` objects and are sometimes sorted simply to get a deterministic order, for example in `Process.waitall` results. The numeric ordering itself has no process-specific meaning, but preserving sortability is convenient. * Should `Process::ID#wait` accept the same integer flags as existing wait APIs, provide keyword arguments, or support both? Integer flags such as `Process::WNOHANG` are consistent with `Process.waitpid`, while keywords such as `nohang: true`, `untraced: true`, and `continued: true` may be more readable for a new convenience method. * Should `Process::ID#detach` simply be equivalent to `Process.detach(self)`? * Are there other process-related APIs that should return or preserve `Process::ID`? -- https://bugs.ruby-lang.org/

5 4

[ruby-core:125586] [Ruby Feature#22085] `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings
by byroot (Jean Boussier) 10 Jun '26

10 Jun '26

Issue #22085 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22085: `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings https://bugs.ruby-lang.org/issues/22085 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- Ruby issue warnings when parsing out of range floats, e.g.: ``` $ ruby -We '1e184467440737095516160.to_s' -e:1: warning: Float 1e184467440737095516... out of range ``` This makes a lot of sense for float literals parsed by the Ruby parser. However I'm not convinced it makes sense when parsing user input or third party data: ```ruby >> '1e184467440737095516160'.to_f (irb):1: warning: Float 1e184467440737095516... out of range => Infinity >> Float('1e184467440737095516160') <internal:kernel>:196: warning: Float 1e184467440737095516... out of range => Infinity ``` As these warnings aren't really actionable in most cases. So I think `String#to_f` and `Kernel#Float` shouldn't issue out of range warnings. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125428] [Ruby Bug#22058] {Method,InstanceMethod}#super_method doesn't work correctly for refined method with refinements for method active in the caller's scope
by jeremyevans0 (Jeremy Evans) 10 Jun '26

10 Jun '26

Issue #22058 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #22058: {Method,InstanceMethod}#super_method doesn't work correctly for refined method with refinements for method active in the caller's scope https://bugs.ruby-lang.org/issues/22058 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.1.0dev (2026-05-03T23:57:21Z master d8d2ed5dc9) +PRISM [x86_64-openbsd7.8] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I've found that Method#super_method and InstanceMethod#super_method do not work correctly in some cases for refined methods. At the least, there is a definite bug, which is that #super_method inside a scope with a refinement activated for the method results in a loop over the refined methods. I'm not sure if the semantics for #super_method for refined methods were ever discussed. Other than the bug regarding the loop over the refinement, the currently semantics seem to be: * While handling additional refined methods for the same class as the current method, #super_method will consider the refinements active at the point the method was created * For ancestors, #super_method will consider the refinements active in the scope calling #super_method These semantics seem questionable. My guess is they are not the result of intentional design, but due purely to implementation details. I see two possibilities: 1. Keep the current behavior, where results depend on refinements activated in the caller's namespace. In this case, I recommend that we not have different handling when there are other refinements for the same class as the current method should. If refinements are not in scope, #super_method should not return them. We should also consider whether #super_method should error if the receiver is a refinement method for a refinement not activated in the caller's scope. 2. Change #super_method so that it depends on the refinements activated in the namespace it was created in, for ancestors as well as for the current class. This would make #super_method return the same result no matter where it was called. I think option 2 makes more sense, but it requires that Method/InstanceMethod objects for refined methods keep a reference to the scope in which they were created. A related minor bug I found during this research is the #inspect output for #super_method results for refined methods also does not use the same format, indicating there is something internally different. Here's example code showing these issues, with commented output below: ```ruby class B def b = 16 end class A < B def b = 8 + super end module M1 refine(A){def b = 1 + super} end module M2 refine(A){def b = 2 + super} end module M3 refine(A){def b = 4 + super} end module M4 refine(B){def b = 4 + super} end I = A.new.method(:b) C = A.instance_method(:b) module N0 using M1 using M3 I = A.new.method(:b) C = A.instance_method(:b) end module N using M1 using M2 using M3 using M4 I = A.new.method(:b) C = A.instance_method(:b) puts "", "Inside module using all refinements using method created using all refinements:" p I i = I 6.times do i = i.super_method p i end puts p C c = C 6.times do c = c.super_method p c end puts "", "Inside module using all refinements using method created using some refinements:" p N0::I i = N0::I 6.times do i = i.super_method p i end puts p N0::C c = N0::C 6.times do c = c.super_method p c end puts "", "Inside module using all refinements using method created using no refinements:" p ::I i = ::I 6.times do break unless i = i.super_method p i end puts p ::C c = ::C 6.times do break unless c = c.super_method p c end end module N0 using M1 using M3 puts "", "Inside module using some refinements using method created using all refinements:" p N::I i = N::I 6.times do break unless i = i.super_method p i end puts p N::C c = N::C 6.times do break unless c = c.super_method p c end end puts "", "Top level using method created with all refinements:" p N::I i = N::I 6.times do break unless i = i.super_method p i end puts p N::C c = N::C 6.times do break unless c = c.super_method p c end puts "", "Top level using method created with some refinements:" p N0::I i = N0::I 6.times do break unless i = i.super_method p i end puts p N0::C c = N0::C 6.times do break unless c = c.super_method p c end puts "", "Top level using method created with no refinements:" p I i = I 6.times do break unless i = i.super_method p i end puts p C c = C 6.times do break unless c = c.super_method p c end ``` First, the bug. This shows a loop among active refinements. After going through M3, M2, and M1, it loops back to M3. This also shows weird #inspect output, with #super_method not showing the main class. ``` Inside module using all refinements using method created using all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> ``` This shows the dynamic scoping of the #super_method. At time of call, only M3 and M1 are in scope. You see in the first loop, only M3 and M1 are used, but subsequent loops use M3, M2, and M1. ``` Inside module using all refinements using method created using some refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> ``` This shows a case where the Method was created with no refinements activated. Refinements for superclasses that are active in the current scope are still picked up: ``` Inside module using all refinements using method created using no refinements: #<Method: A#b() t/t43.rb:30> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<Method: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> #<UnboundMethod: #<refinement:B@M4>#b() t/t43.rb:46> ``` More evidence for dynamic scoping. This is the opposite of the second example, where the first loop has M3, M2, and M1, and subsequent loops have M3 and M1. ``` Inside module using some refinements using method created using all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: #<refinement:A@M3>#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> ``` This shows the behavior when no refinements are activated in the current scope. It still includes refinements for the same class as the current method, but no refinements for superclasses. Also, note that there is no longer a loop, because there are no refinements activated: ``` Top level using method created with all refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M2>#b() t/t43.rb:38> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M2>#b() t/t43.rb:38> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` This shows that only the refinements were activated at the point the method was created are included. ``` Top level using method created with some refinements: #<Method: A(#<refinement:A@M3>)#b() t/t43.rb:42> #<Method: #<refinement:A@M1>#b() t/t43.rb:34> #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: #<refinement:A@M3>#b() t/t43.rb:42> #<UnboundMethod: #<refinement:A@M1>#b() t/t43.rb:34> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` This output doesn't show any problems, it shows that if refinements were not activated when the method was created, and are not activated when #super_method is called, that #super_method ignores refinements, which is what you would expect. ``` Top level using method created with no refinements: #<Method: A#b() t/t43.rb:30> #<Method: B#b() t/t43.rb:26> #<UnboundMethod: A#b() t/t43.rb:30> #<UnboundMethod: B#b() t/t43.rb:26> ``` -- https://bugs.ruby-lang.org/

4 14

[ruby-core:125675] [Ruby Bug#22101] ASAN heap-use-after-free in rb_data_free after TypedData dfree frees dynamic rb_data_type_t
by rwstauner (Randy Stauner) 10 Jun '26

10 Jun '26

Issue #22101 has been reported by rwstauner (Randy Stauner). ---------------------------------------- Bug #22101: ASAN heap-use-after-free in rb_data_free after TypedData dfree frees dynamic rb_data_type_t https://bugs.ruby-lang.org/issues/22101 * Author: rwstauner (Randy Stauner) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- `rb_data_free` currently calls `dfree` and then evaluates `RTYPEDDATA_EMBEDDABLE_P(obj)`. Since `RTYPEDDATA_EMBEDDABLE_P(obj)` reads `RTYPEDDATA_TYPE(obj)->flags`, this can become a use-after-free if an extension's `dfree` releases a dynamically allocated `rb_data_type_t`. This was observed under ASAN with `glib2` 4.3.6, where `cinfo_free` frees `cinfo->data_type`. I have a fix that simply caches the TypedData type and the embeddable/free decision before invoking `dfree`, matching the existing pattern of caching `dfree` and `RUBY_TYPED_FREE_IMMEDIATELY` before extension cleanup code runs: https://github.com/ruby/ruby/pull/17266 This is a small defensive fix and is suitable for backport because it avoids a shutdown-time ASAN heap-use-after-free without changing TypedData ownership semantics. -- https://bugs.ruby-lang.org/

1 3

[ruby-core:113430] [Ruby master Feature#19633] Allow passing block to `Kernel#autoload` as alternative to second `filename` argument
by shioyama (Chris Salzberg) 10 Jun '26

10 Jun '26

Issue #19633 has been reported by shioyama (Chris Salzberg). ---------------------------------------- Feature #19633: Allow passing block to `Kernel#autoload` as alternative to second `filename` argument https://bugs.ruby-lang.org/issues/19633 * Author: shioyama (Chris Salzberg) * Status: Open * Priority: Normal ---------------------------------------- `Kernel#autoload` takes two arguments, a symbol `module` representing the constant to be autoloaded, and a `filepath` to load the constant from (with `require`). Currently, Zeitwerk has to [monkeypatch `Kernel#require`](https://github.com/fxn/zeitwerk/blob/a7c4a983df0f4e4058f32c610dac1e8b99f687da/lib/zeitwerk/kernel.rb) to fetch the loader for the file being loaded, then run the original (aliased) `require`, then run autoload callbacks. In addition to the monkeypatch, this also requires a registry (`Zeitwerk::Registry`) to map file paths to loaders, to know which loader should be used for a given autoload-triggered `require`. In fact, Zeitwerk has to _assume_ that the monkey-patched `require` call came from an autoload trigger; there is no way to really be sure of the source. If Ruby allowed passing a block as an alternative to the explicit filepath, then I think this could be improved and would eliminate the need for a monkeypatch. So something like this: ```ruby autoload(:B) do require "lib/b" # trigger callback, etc end ``` I am implementing a gem called [Im](https://github.com/shioyama/im) which is a fork of Zeitwerk, and in the case of this gem, such a feature would be even more useful. Im implements autoloads on anonymous modules by registering an autoload and then "catching" the require and converting it into a `load`, passing the module as the second argument (see [here](https://github.com/shioyama/im/blob/44ce348639a1aae563a5be7a40602761e….) This is currently quite tricky because, again, it's hard to know _where_ a `require` came from. In addition to removing the monkeypatch (inherited from Zeitwerk), Im would further benefit from the block argument because then it could simply access the module via a closure, rather than pulling it from a registry: ```ruby mod.autoload(:Foo) do load "lib/foo.rb", mod end ``` I don't know how hard or easy this would be to implement, but if there is interest in this as a feature I'd be happy to look into implementing it. -- https://bugs.ruby-lang.org/

4 16

[ruby-core:125252] [Ruby Bug#21996] Crash when modifying instance variables during inspect or Marshal dump
by jhawthorn (John Hawthorn) 10 Jun '26

10 Jun '26

Issue #21996 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Bug #21996: Crash when modifying instance variables during inspect or Marshal dump https://bugs.ruby-lang.org/issues/21996 * Author: jhawthorn (John Hawthorn) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- In #15968 describes an issue where instance variables being modified lead to incorrect Marshal output being generated, which was partially solved by checking for the number of IVs changing and raising an exception. However, if enough IVs removed this could cause the buffer to be moved/re-embedded, but we'd still attempt to read the now removed variables. I've found this reproduces back to Ruby 3.3, but suspect there are other ways to hit issues on older versions. We've seen the test from #15968 start failing on CI recently (likely because the changes to size pools makes this crash reproducible) https://github.com/ruby/ruby/actions/runs/24247666394/job/70803324392 ``` ruby class Evil def initialize(parent) @parent = parent end def marshal_dump @parent.instance_variables.each { |v| @parent.remove_instance_variable(v) } {} end def marshal_load(data) = nil end obj = Object.new obj.instance_variable_set(:@evil, Evil.new(obj)) 10.times { |i| obj.instance_variable_set(:"@v#{i}", 0) } Marshal.dump(obj) # SEGV ``` ``` ruby class Evil def initialize(parent) @parent = parent end def inspect @parent.instance_variables.each { |v| @parent.remove_instance_variable(v) } "" end end obj = Object.new obj.instance_variable_set(:@evil, Evil.new(obj)) 10.times { |i| obj.instance_variable_set(:"@v#{i}", 0) } obj.inspect # SEGV ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125661] [Ruby Bug#22099] Keyword-only method silently accepts a positional argument
by rumoto (Hiroki Motoyoshi) 10 Jun '26

10 Jun '26

Issue #22099 has been reported by rumoto (Hiroki Motoyoshi). ---------------------------------------- Bug #22099: Keyword-only method silently accepts a positional argument https://bugs.ruby-lang.org/issues/22099 * Author: rumoto (Hiroki Motoyoshi) * Status: Open * ruby -v: ruby 3.4.9 (2026-03-11 revision 76cca827ab) +PRISM [arm64-darwin24] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- A method that declares only keyword parameters accepts a positional argument without raising, but only from the second call onward; a prior valid keyword call to the same method is required to trigger it. Once triggered, the positional value is bound to the first keyword and an explicitly passed keyword of the same name is dropped. ```ruby class Foo def bar(a: nil, b: nil) p [:body, a: a, b: b] end end foo = Foo.new foo.bar(a: 1, b: 2) #=> [:body, {a: 1, b: 2}] foo.bar(99, a: 0) #=> [:body, {a: 99, b: nil}] foo.bar(99, b: 0) #=> [:body, {a: nil, b: 99}] ``` Although one positional argument is passed, no exception is raised. The positional value (`99`) is bound to the first keyword `a`, and the explicitly passed keyword (`a: 0` / `b: 0`) is not reflected in the result. Since `bar` accepts no positional arguments, an `ArgumentError (wrong number of arguments (given 1, expected 0))` should be raised. -- https://bugs.ruby-lang.org/

3 2

[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