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

[ruby-core:114943] [Ruby master Bug#19910] Set#delete_if behavior inconsistent with Array/Hash
by segiddins (Samuel Giddins) 16 Aug '26

16 Aug '26

Issue #19910 has been reported by segiddins (Samuel Giddins). ---------------------------------------- Bug #19910: Set#delete_if behavior inconsistent with Array/Hash https://bugs.ruby-lang.org/issues/19910 * Author: segiddins (Samuel Giddins) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Given the following script: ```ruby #!/usr/bin/env ruby require 'set' def enum(collection) i = 0 collection.delete_if do i += 1 raise ArgumentError if i == 6 i.odd? end rescue ArgumentError return collection end pp enum([0, 1, 2, 3, 4, 5, 6, 7]) pp enum([0, 1, 2, 3, 4, 5, 6, 7].to_h { [_1, _1] }) pp enum([0, 1, 2, 3, 4, 5, 6, 7].to_set) ``` It results in: ``` [1, 3, 5, 6, 7] {1=>1, 3=>3, 5=>5, 6=>6, 7=>7} #<Set: {0, 1, 2, 3, 4, 5, 6, 7}> ``` As you can see, when an exception is raise inside `delete_if` on Hash/Array, the already-considered elements are still removed from the array. For `Set`, no elements are deleted (due to the implementation that builds up an intermediary list of elements to delete, then removes them from the underlying hash afterwards). It would be very helpful if `Set#delete_if` behaved consistently with other core collection types -- https://bugs.ruby-lang.org/

5 4

[ruby-core:125003] [Ruby Feature#21953] Allow accessing unshareable objects within a Ractor-local Ruby Box
by tikkss (Tsutomu Katsube) 16 Aug '26

16 Aug '26

Issue #21953 has been reported by tikkss (Tsutomu Katsube). ---------------------------------------- Feature #21953: Allow accessing unshareable objects within a Ractor-local Ruby Box https://bugs.ruby-lang.org/issues/21953 * Author: tikkss (Tsutomu Katsube) * Status: Open ---------------------------------------- ### Status Currently, non-main ractors prohibit access to the following objects to prevent data races: * Global variables * Class variables * Unshareable class instance variables * Unshareable constants ### Proposal I would like to propose that allow reading/writing unshareable objects inside a Ruby Box created in a non-main ractor: ```ruby # lib/x.rb class X # can write unshareable objects XXX = "1" @@cvar = "1" @ivar = "1" class << self def cvar; @@cvar; end def ivar; @ivar; end end end # can read unshareable objects $LOAD_PATH # => returns $LOAD_PATH includes lib directory X.cvar # => "1" X.ivar # => "1" X::XXX # => "1" # main.rb Ractor.new do local_box = Ruby::Box.new local_box.eval <<~RUBY base_dir = File.expand_path(File.dirname(__FILE__)) lib_dir = File.join(base_dir, "lib") # can write unshareable objects $LOAD_PATH.unshift(lib_dir) RUBY local_box.require("x") x = local_box::X.new end.join ``` Ruby Box can isolate global/class variables, class/module definitions from other boxes. A Ruby Box created inside a non-main ractor cannot be accessed from other ractor. If that is the case, wouldn’t it be fine to access unshareable objects inside that box? So I would like to propose that allow reading/writing unshareable objects inside a Ruby Box created in a non-main ractor. ### Background We are working on implementing a Ractor based parallel test runner for the test-unit gem. Ractor is a great for parallel processing. However, many existing libraries still rely on class variables or class instance variables for configuration. Ideally, we should reduce the use of class variables or class instance variables. Currently, we tried fixing several non-shareable objects, but we could not resolve all of them yet. We will continue working on this issue, but we are also exploring other approaches. This is the idea begind this proposal. I think the work needed to make objects shareable when running exisiting libraries with Ractor can be reduced. ### FAQ Q: Can we create a Ruby Box inside a non-main ractor? A: Yes: ```ruby Ractor.new {Ruby::Box.new}.join ``` Q: Is a Ruby Box created in a non-main ractor truly inaccessible from other ractor? A: No. I'm not sure if it's intentional, but a Ruby Box is a shareable object. Also, it can be accessed from the main Ractor by using `Ractor#value`: ```ruby Ractor.shareable?(Ruby::Box.new) # => true ``` ```ruby Ractor.new {Ruby::Box.new}.value # => #<Ruby::Box:3,user,optional> ``` To implement this proposal, Ruby Box may need to be an unshareable object, and passing it with `Ractor#value` may need to be disallowed. -- https://bugs.ruby-lang.org/

5 13

[ruby-core:126397] [Ruby Bug#22247] Add Ractor.movable?
by rkh (Konstantin Haase) 15 Aug '26

15 Aug '26

Issue #22247 has been reported by rkh (Konstantin Haase). ---------------------------------------- Bug #22247: Add Ractor.movable? https://bugs.ruby-lang.org/issues/22247 * Author: rkh (Konstantin Haase) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-15T07:21:53Z master d1c079751b) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Some objects cannot be moved (like unshareable lambdas). It would be great to have a method to check whether an object is movable, similar to `Ractor.shareable?`. Not 100% sure what it should return for shareable objects, but I would lean towards `true` as well (despite them not being moved), as they can be passed to `Ractor.send(object, move: true)`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126391] Re: Useless Copilot 'comments'
by Martin J. Dürst 14 Aug '26

14 Aug '26

Hello Hiroshi, Sorry this mail is late. Many thanks for changing the settings, this works very well now! Regards, Martin. On 2026-07-27 11:30, SHIBATA Hiroshi wrote: > I have turned off the automatic Copilot review on the ruby repository. If > you still want a review from Copilot on a specific pull request, you can > get one by assigning Copilot as a reviewer. > > Note that this does not cover every case. A review can still be requested > depending on the contributor's own Copilot configuration, or on the > settings of the organization that provides them with Copilot. > > We cannot control either of those from the ruby org side. There are also > reports of reviews firing even when everything is turned off, so a problem > on the GitHub side is possible. > > Also, once Copilot is assigned as a reviewer, there is no setting to > suppress the comment it posts. This includes comments stating it has > nothing to add or that the quota has been reached. Please filter those > emails on your side. If you want this changed, the request needs to go to > GitHub, so please send them your feedback directly. > > On Sun, Jul 26, 2026 at 9:29 AM Martin J. Dürst via ruby-core < > ruby-core(a)ml.ruby-lang.org> wrote: > >> The amount of mail I get as a Ruby committer is already significant, but >> lately, it has been getting worse. Copilot is producing additional >> mails. And most of them are useless: >> >> 1) There are the regurgitating mails. See the comment from Earlopain >> below for why we don't need these. >> >> 2) There are the mails that say it has no comment. >> No actual committer sends such mails. >> >> 3) There are the mails that say that it "was unable to review this pull >> request because the user who requested the review has reached their >> quota limit.". >> No actual committer sends out mails e.g. saying they are currently >> busy with their day job. >> >> Can we change the settings so that such emails are not sent anymore? >> Maybe just switch off Copilot, and have people who think it might >> produce useful comments activate it manually for specific commits? >> I don't really care too much about the specifics; any improvement to >> this situation is welcome. >> >> Regards, Martin. >> >> >> -------- Forwarded Message -------- >> Subject: Re: [ruby/ruby] Reject reopening `false` when assigned to >> constant (PR #18064) >> Date: Sat, 25 Jul 2026 02:57:24 -0700 >> From: Earlopain <notifications(a)github.com> >> Reply-To: ruby/ruby >> <reply+AAGHDTMCZMSKXP3WLV2J543K3XQJJEVBNHHQAAAAAEUIY3SX(a)reply.github.com> >> To: ruby/ruby <ruby(a)noreply.github.com> >> CC: Subscribed <subscribed(a)noreply.github.com> >> >> Earlopain left a comment (ruby/ruby#18064) >> >> Thanks to the stochastic model for regurgitating what I have already >> written in 10x the verbosity, much appreciated. >> >> -- >> Reply to this email directly or view it on GitHub: >> https://github.com/ruby/ruby/pull/18064#issuecomment-5078055845 >> You are receiving this because you are subscribed to this thread. >> >> Message ID: <ruby/ruby/pull/18064/c5078055845(a)github.com> >> >> ______________________________________________ >> ruby-core mailing list -- ruby-core(a)ml.ruby-lang.org >> To unsubscribe send an email to ruby-core-leave(a)ml.ruby-lang.org >> ruby-core info -- >> https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/ >> >> > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan

1 0

[ruby-core:126134] [Ruby Feature#22205] Add deprecation warnings for ruby2_keywords
by shugo (Shugo Maeda) 14 Aug '26

14 Aug '26

Issue #22205 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22205: Add deprecation warnings for ruby2_keywords https://bugs.ruby-lang.org/issues/22205 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- # Add deprecation warnings for ruby2_keywords I believe ruby2_keywords should be removed in the future, but removing it now would cause compatibility issues. As a first step, how about adding deprecation warnings to ruby2_keywords? At least the following methods should emit a warning: * Module#ruby2_keywords * main.ruby2_keywords * Proc#ruby2_keywords The following methods are relatively harmless, so it might be better not to warn on them in the first step: * Hash.ruby2_keywords_hash? * Hash.ruby2_keywords_hash ## Background and Motivation While implementing Proc#refined, I noticed that the ruby2_keywords flag on an iseq (param.flags.ruby2_keywords) can be mutated by Proc#ruby2_keywords even when the iseq is shared among multiple Ractors, which is not Ractor-safe. I consider ruby2_keywords a negative legacy, and I would rather deprecate it than fix such behavior. -- https://bugs.ruby-lang.org/

8 13

[ruby-core:126386] [Ruby Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by zverok (Victor Shepelev) 13 Aug '26

13 Aug '26

Issue #18915 has been updated by zverok (Victor Shepelev). > The new exception class should inherit from ScriptError, not StandardError. Failing to define a method that a subclass is required to provide is a problem in the program itself, the same kind of problem as SyntaxError or LoadError, not a runtime error. @matz, we just discussed this future change with colleagues (got bit by `NotImplementedError` in our codebase, and I remembered the ongoing core discussion), and I think they made a good counter-argument: **The "this object's method is not implemented" is an error of the same severity class as "this object doesn't have such method at all" (aka `NoMethodError`), and the latter is a descendant of a `StandardError`.** The difference from `SyntaxError`/`LoadError` is that "this method is not implemented" usually happens in runtime, not while the codebase is loaded, and so it not being caught by standard `rescue` might be undesirable. Imagine some code like: ```ruby payloads.each do |payload| driver = Driver.create_for(payload[:type]) # fetches different Driver subclasses driver.process(payload) rescue => ex log.error("payload #{payload} is unprocessable: #{ex.message}") end ``` If we have like 10 different drivers, and one of them didn't implement the necessary method, this will bite the developer somewhere in the middle of the code handling something, not in a "code can't be loaded at all" way. WDYT? ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-118523 * 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:126383] [Ruby Bug#18444] Trapped TSTP causes a locking deadlock in 3.0.3 onward
by wanabe (_ wanabe) 13 Aug '26

13 Aug '26

Issue #18444 has been updated by wanabe (_ wanabe). File 18444.log added This issue can also be reproduced on the master branch. Since it is not specific to TSTP, it can be reproduced with any signal. ``` $ ./miniruby -ve 'Signal.trap(:TERM) { print "2\r"; sleep 0.01; exit(0) }; spawn("sleep 0.1; kill -TERM #{$$}"); loop {print "1\r"}' ruby 4.1.0dev (2026-08-12T02:39:28Z origin/master c6e9858440) +PRISM [x86_64-linux] -e:1:in 'IO#write': deadlock; recursive locking (ThreadError) from -e:1:in 'Kernel#print' from -e:1:in 'block in <main>' from -e:1:in 'IO#write' from -e:1:in 'Kernel#print' from -e:1:in 'block in <main>' from -e:1:in 'Kernel#loop' from -e:1:in '<main>' ``` I attached the backtrace captured with GDB. Summary: ``` print "1\r" # print in loop{} -> #44 0x00005555557005d5 in io_binwrite (ptr=0x55555606e810 "1\r", len=2, fptr=0x555555f26c40, nosync=0) at ../../io.c:1939 #43 0x000055555589676c in rb_mutex_synchronize (self=140737345534480, func=0x555555700320 <io_binwrite_string>, arg=140737488338256) at ../../thread_sync.c:629 #42 0x00005555556b408c in rb_ec_ensure (ec_arg=0x555555ebff58, b_proc=0x555555700320 <io_binwrite_string>, data1=140737488338256, e_proc_arg=0x555555896318 <do_mutex_unlock_safe>, data2_arg=140737488338176) at ../../eval.c:1171 #40 0x000055555570030a in io_binwrite_string_internal (fptr=0x555555f26c40, ptr=0x55555606e810 "1\r", length=2) at ../../io.c:1817 #38 0x00005555556fdf28 in rb_io_blocking_region_wait (io=0x555555f26c40, function=0x5555556ff0db <internal_write_func>, argument=0x7fffffffbac0, events=RUBY_IO_WRITABLE) at ../../io.c:230 #35 0x000055555589d86e in rb_threadptr_execute_interrupts (th=0x555555ea0780 <_main_thread>, blocking_timing=1) at ../../thread.c:2820 Signal.trap(:TERM) -> #34 0x000055555584688a in rb_signal_exec (th=0x555555ea0780 <_main_thread>, sig=15) at ../../signal.c:1143 #33 0x00005555558466ef in signal_exec (cmd=140737345533960, sig=15) at ../../signal.c:1081 #32 0x00005555559106d9 in rb_eval_cmd_call_kw (cmd=140737345533960, argc=1, argv=0x7fffffffb778, kw_splat=0) at ../../vm_eval.c:2196 print "2\r" # print in trap{} -> #3 0x00005555557005d5 in io_binwrite (ptr=0x55555606e8c0 "2\r", len=2, fptr=0x555555f26c40, nosync=0) at ../../io.c:1939 #2 0x000055555589674a in rb_mutex_synchronize (self=140737345534480, func=0x555555700320 <io_binwrite_string>, arg=140737488328896) at ../../thread_sync.c:628 #1 0x0000555555895bf4 in do_mutex_lock (args=0x7fffffff9870, interruptible_p=1) at ../../thread_sync.c:296 #0 rb_raise (exc_class=93824993755556, fmt=0x7fffffff9710 "@\227\377\377\377\177") at ../../error.c:3930 ``` - Since `rb_signal_exec` is executed - while STDOUT is locked by the `print` statement in the main loop, - a problem occurs when attempting to use `print` within the `trap` block - because STDOUT is still locked. Ideally, this issue could be resolved by ensuring that `rb_signal_exec` is executed only after the lock is released by the first `print` statement in the main loop. But I am concerned that doing so might compromise compatibility. ---------------------------------------- Bug #18444: Trapped TSTP causes a locking deadlock in 3.0.3 onward https://bugs.ruby-lang.org/issues/18444#change-118519 * Author: why-el (Mohamed Wael Khobalatte) * Status: Open * ruby -v: 3.0.3 * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- A curious case: `ruby -e 'Signal.trap("TSTP") { puts "Received a terminal stop signal, but i will sleep instead."; sleep 10 }; loop {puts 1}'` this fails with `deadlock; recursive locking (ThreadError)` when I send the SIGTSTP via my terminal. This is on Mac OS Monterey (M1). It only happens in 3.0.3 and onward (I tried 3.1.0-preview1 as well, fails there too), when I try 3.0.2, the signal is handled properly. ---Files-------------------------------- 18444.log (11.8 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126210] [Ruby Misc#22221] DevMeeting-2026-08-06
by mame (Yusuke Endoh) 12 Aug '26

12 Aug '26

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

[ruby-core:121829] [Ruby Feature#21308] Replacing the Float#to_s (dtoa.c) implementation with a modern algorithm
by watson1978 (Shizuo Fujita) 12 Aug '26

12 Aug '26

Issue #21308 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Feature #21308: Replacing the Float#to_s (dtoa.c) implementation with a modern algorithm https://bugs.ruby-lang.org/issues/21308 * Author: watson1978 (Shizuo Fujita) * Status: Open ---------------------------------------- This is a feature request to replace Ruby's `Float#to_s` implementation with a modern high-performance float-to-string conversion algorithm such as Grisu. Currently, `Float#to_s` in Ruby uses the BSD-derived implementation in [missing/dtoa.c](https://github.com/ruby/ruby/blob/master/missing/dtoa.c). Meanwhile, `json` gem has adopted a Grisu-based implementation in [ruby/json#768](https://github.com/ruby/json/pull/768), it has been improve the performance of float-to-string conversion dramatically. It appears to have brought about a 10 times improvement in performance. However, the improvement is limited to the `json` gem. If we can use the same implementation in `Float#to_s`, it will introduce the improvement in all float-to-string conversion cases. (In additional, it would be better if an API could be added that could be called directly from the C extension library, it will reduce the overhead of the call.) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126369] [Ruby Bug#22241] Restore compatibility for removed `JSON.dump` and `JSON.parse` arguments
by nobu (Nobuyoshi Nakada) 12 Aug '26

12 Aug '26

Issue #22241 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22241: Restore compatibility for removed `JSON.dump` and `JSON.parse` arguments https://bugs.ruby-lang.org/issues/22241 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: byroot (Jean Boussier) * Target version: 4.1 * ruby -v: f51515f39a13223ce784eb3412c1f83a8a3960a4 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- JSON 3.0.0.rc1 removes two previously accepted arguments without a deprecation period: ```ruby JSON.dump(object, io, 0) JSON.parse(source, quirks_mode: true) ``` The first call now raises `TypeError` because the third positional argument is treated as an options hash. The second raises `ArgumentError` because `quirks_mode` is no longer recognized. Neither usage produces a deprecation warning with JSON 2.21.2, even with warnings enabled: ```ruby Warning[:deprecated] = true ``` This currently breaks downstream test suites. RDoc used the third `JSON.dump` argument when generating its JSON index, while `json-schema` 5.1.0 passes `quirks_mode: true`, causing RBS schema tests in the Ruby repository to fail. Because JSON is a default gem, downstream projects cannot always avoid the breakage by pinning an older version, especially when testing against Ruby head. Could JSON 3.0 continue accepting these arguments for compatibility? `quirks_mode` can presumably be accepted and ignored now that top-level scalar values are parsed by default. The positional `limit` argument could similarly remain supported until it has gone through a deprecation cycle. -- https://bugs.ruby-lang.org/

2 5