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

[ruby-core:126356] [Ruby Feature#22238] String#tr to take a Hash for multi-character replacements
by byroot (Jean Boussier) 14 Aug '26

14 Aug '26

Issue #22238 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22238: String#tr to take a Hash for multi-character replacements https://bugs.ruby-lang.org/issues/22238 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- This is @matz's counter proposal to [Feature #22229] from the last dev-meeting > matz: I will counter-propose String#tr-with-hash style. ```ruby 'Hello </script>'.tr(">" => '\u003e', "<" => '\u003c', "&" => '\u0026') # matz: OK 'Hello </script>'.tr("abc" => 'ABC') # should raise an exception 'Hello </script>'.tr("abc" => 'ABC', "ab" => "XY") # should raise an exception "fée".tr("é" => "€") # it should work "Hello".tr("l" => "ABC", "o" => "XYZ") #=> "HeABCABCXYZ" "Hello".gsub(/./m) { hash[$&] || $& } # gsub equivalent ``` Notes: - Hash keys MUST be single characters (but can be multi-byte). - Values can be multiple characters. -- https://bugs.ruby-lang.org/

3 4

[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:126381] [Ruby Feature#22244] `ruby -UU` should set both internal and external, `ruby -E` should print encoding list
by zenspider (Ryan Davis) 13 Aug '26

13 Aug '26

Issue #22244 has been reported by zenspider (Ryan Davis). ---------------------------------------- Feature #22244: `ruby -UU` should set both internal and external, `ruby -E` should print encoding list https://bugs.ruby-lang.org/issues/22244 * Author: zenspider (Ryan Davis) * Status: Open ---------------------------------------- ``` 10004 $ env -u LANG ruby -U -e 'pp [Encoding.default_internal, Encoding.default_external]' [#<Encoding:UTF-8>, #<Encoding:US-ASCII>] 10005 $ env -u LANG ruby -EUTF-8 -e 'pp [...]' [nil, #<Encoding:UTF-8>] 10006 $ env -u LANG ruby -EUTF-8 -U -e 'pp [...]' [#<Encoding:UTF-8>, #<Encoding:UTF-8>] 10007 $ env -u LANG ruby -EUTF-8:UTF-8 -e 'pp [...]' [#<Encoding:UTF-8>, #<Encoding:UTF-8>] 10008 $ env -u LANG ruby -UU -e 'pp [...]' [#<Encoding:UTF-8>, #<Encoding:US-ASCII>] ``` I think the option processing of encodings is VERY poorly documented and frustrating to try to use. 1. --help doesn't list -U. (The man page does) 2. --help for -E doesn't provide a means to get a list of available encoding names (same with manpage), leading me to try U, UTF8, UTF_8, before finding UTF-8. `ruby -E` could just print them all out. 3. WHY NOT take UTF8 or UTF_8 (since that's the class name)? 4. Please consider `-UU` to mean `-EUTF-8:UTF-8` -- https://bugs.ruby-lang.org/

1 2

[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:126379] [Ruby Feature#22243] Change fork behavior when Process._fork raises an exception during fork with a block argument
by rpeng (Richard Peng) 13 Aug '26

13 Aug '26

Issue #22243 has been reported by rpeng (Richard Peng). ---------------------------------------- Feature #22243: Change fork behavior when Process._fork raises an exception during fork with a block argument https://bugs.ruby-lang.org/issues/22243 * Author: rpeng (Richard Peng) * Status: Open ---------------------------------------- # Problem Ruby exposes Process.fork in two formats - one with block arguments and one without. When a block is passed in, the implicit contract is that a child process will terminate once the block ends. However, it is possible for the child to "escape" the enclosed block in certain circumstances when Process._fork raises an exception. Here's a demonstration of what may occur: ```ruby module BadForkTracker def _fork pid = super if pid == 0 raise "exception during fork in child" # end pid end end Process.singleton_class.prepend(BadForkTracker) loop do sleep(1) puts "I'm parent #{Process.pid}" fork do puts "I'm child #{Process.pid} and I'm exiting" end rescue StandardError => e puts "#{Process.pid} Received Error: #{e}" # <- child ends up in this block, then resumes the loop. most users will not be expecting this. end ``` In practice, there are many libraries that implement "fork tracking" (active_support, datadog, connection_pool, to name a few) by prepending to the `Process` module. Many of which are designed to run user specified callbacks which increases the surface area of errors occurring. This means that on _fork, there's a good chance that something will throw and cause a child to resume execution in the "parent" context. In addition, many workloads (sidekiq, puma) have global rescues that are similar to the example case I provided above, which would unintentionally cause the child to continue execution. # Proposal I am proposing a change in behavior: when Process.fork is called with a block, if Process._fork raises an exception in the child, immediately terminate the child with an error exit code (instead of relying on an enclosing rescue to handle it). This guarantees that a child cannot escape out of the block it was meant to execute. In my opinion, this is more in line with how libraries generally expect this to work (e.g. there are very few libraries that are being defensive and attempting not to throw in `def _fork` overrides). -- https://bugs.ruby-lang.org/

3 3

[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