October 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:123319] [Ruby Feature#21615] Introduce `Array#values`
by matheusrich (Matheus Richard) 23 Oct '25

23 Oct '25

Issue #21615 has been reported by matheusrich (Matheus Richard). ---------------------------------------- Feature #21615: Introduce `Array#values` https://bugs.ruby-lang.org/issues/21615 * Author: matheusrich (Matheus Richard) * Status: Open ---------------------------------------- ## Motivation In Ruby code, it's common to accept arrays and hashes and treat them uniformly as collections of values. `Hash` exposes `#values`, but `Array` does not, which pushes developers toward `is_a?`/`respond_to?` branching. Following the **Principle of Least Surprise**, users may reasonably expect `Array#values` to exist because: * Both `Array` **and** `Hash` already implement `#values_at`. * `Hash` implements `#values` but `Array` does not. ### Example Today: ```ruby def normalize_records(input) items = input.respond_to?(:values) ? input.values : input items.each do |item| do_stuff_with_item(item) end end ``` With `Array#values`: ```ruby def normalize_records(input) input.values.each do |item| do_stuff_with_item(item) end end ``` ## Proposal Add `Array#values`, returning `self`. Implementation could simply alias to `itself`: ```ruby class Array alias_method :values, :itself end ``` This yields a uniform interface for `Array` and `Hash` values without type checks. ### Alternatives considered * `Enumerable#values`: defaulting to `to_a`, but I found it too broad of a change. * `Array#each_value`: redundant as `Array#each` already covers iteration. Patch: https://github.com/ruby/ruby/pull/14641 -- https://bugs.ruby-lang.org/

6 8

[ruby-core:118243] [Ruby master Feature#20564] Switch default parser to Prism
by kddnewton (Kevin Newton) 22 Oct '25

22 Oct '25

Issue #20564 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #20564: Switch default parser to Prism https://bugs.ruby-lang.org/issues/20564 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- This issue is to propose switching the default parser for Ruby to Prism on the master branch. The main goal is to get this default into both master and the next preview so that the community has plenty of time to test before the eventual 3.4 release. Matz has indicated that the final decision about the default parser for Ruby 3.4 will be made later in the year. Decisions about the default parser for Ruby 3.5+ and the relationship between Prism, lrama, parse.y, etc. will also be made at a later time. ## Background For some background on the Prism project itself, here are a couple of links in chronological order that you can read: * https://bugs.ruby-lang.org/issues/19741 * https://railsatscale.com/2023-06-12-rewriting-the-ruby-parser/ * https://kddnewton.com/2024/01/23/prism.html * https://railsatscale.com/2024-04-16-prism-in-2024/ ## Status Prism now passes all Ruby tests and specs. Internally at Shopify, it also passes our Core monolith's CI, which is a large and complex Rails application. We are confident that it is ready for production use. External to CRuby, Prism has already been adopted extensively around the ecosystem, including but not limited to: * [JRuby](https://github.com/jruby/jruby/pull/8103) (via Java) * [TruffleRuby](https://github.com/oracle/truffleruby/issues/3117) (via Java) * [Natalie](https://github.com/natalie-lang/natalie/pull/1213) (via C++ and Ruby) * [Opal](https://github.com/opal/opal/pull/2642) (via Ruby and WASM) * [repl_type_completor](https://github.com/ruby/repl_type_completor) * [rubocop](https://docs.rubocop.org/rubocop/configuration.html#setting-the-pa… (via parser translator) * [ruby-lsp](https://github.com/Shopify/ruby-lsp) * [packwerk](https://github.com/Shopify/packwerk/pull/388) (via parser translator) Fortunately with the community adoption, we have been able to find many edge cases and bugs that have been fixed. Thank you so much to everyone who has tried, used, reported problems with, and improved Prism in the last couple of years. We would not have hit this milestone without this community involvement. ## Caveats While Prism correctly accepts and parses all valid Ruby syntax, there are still a number of cases where it does not reject invalid syntax as it should. We are currently working on these cases, and we are confident that we can eliminate them before the next preview release. You can find them listed here: https://github.com/ruby/prism/issues?q=is%3Aopen+is%3Aissue+label%3Ainvalid…. This is our top priority right now, and I anticipate these being resolved quickly. The other caveat is unknown unknowns: bugs or syntax issues that we have yet to discover. At Shopify we are currently taking numerous steps to mitigate this risk, including: * Prism currently passes all Ruby tests and specs, and will continue to going forward. The tests and specs are extensive, and we are confident this gets us almost all of the way there. * Grammar-based fuzzing to ensure we handle all possible syntax variations (both valid and invalid). As an example, that recently led to the discovery that the current compiler was segfaulting on safe navigation in for loops (https://bugs.ruby-lang.org/issues/20468) It has also found several memory leaks that have been fixed. * Mutation testing of existing source files (by adding and deleting random bytes) to find additional edge cases. Our goal is 100% compatibility, and we believe this is achievable through the above techniques and others. The goal of this proposal is to allow more companies to test their codebase against Prism, and to make this easier. We believe that we can sort out the remaining problems much more quickly in that manner. ## Implementation The implementation will be relatively straightforward, as there is already the `--parser` flag that can be used to switch between the current parser and Prism. We will change the default to be `"prism"` instead of `"parse.y"`. There is no plan to remove or change any code related to `parse.y`, `lrama`, or `compile.c` at this time, as we want to create the minimal amount of change possible to ensure stability. -- https://bugs.ruby-lang.org/

4 10

[ruby-core:123257] [Ruby Misc#21606] DevMeeting-2025-10-23
by mame (Yusuke Endoh) 22 Oct '25

22 Oct '25

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

7 8

[ruby-core:123473] [Ruby Feature#21636] Proposal to Introduce a Dedicated Warning Category for Regular Expressions
by alexanderadam (Alexander Adam) 21 Oct '25

21 Oct '25

Issue #21636 has been reported by alexanderadam (Alexander Adam). ---------------------------------------- Feature #21636: Proposal to Introduce a Dedicated Warning Category for Regular Expressions https://bugs.ruby-lang.org/issues/21636 * Author: alexanderadam (Alexander Adam) * Status: Open ---------------------------------------- Hi folks, while working on adding regex support for the marcel gem (see PR: https://github.com/rails/marcel/pull/132) I encountered regex warnings triggered by some of Tika’s regular expressions. Typically, these warnings are valid but in this case I'd like to silence them for one single call. Currently, to suppress these warnings, I have overridden `$VERBOSE`, which effectively silences all warnings but also hides potentially important ones. This feels like a blunt instrument that might mask unrelated issues. Fortunately, Ruby already supports dedicated warning categories, as detailed in these discussions and pull requests: * https://bugs.ruby-lang.org/issues/17122 * https://bugs.ruby-lang.org/issues/11588 * https://github.com/ruby/ruby/pull/3505 Given this existing framework, I would like to propose introducing a dedicated warning category for regular expressions. This would allow libraries and applications to suppress only regex-related warnings selectively, for example, with `Warning[:regexp] = false`. Such a feature would provide more granular control over warnings without compromising the visibility of other important warnings. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:123496] [Ruby Feature#21642] Introduce `IO::ConnectionReset` and `IO::BrokenPipe` as standardized IO-level exceptions.
by ioquatix (Samuel Williams) 21 Oct '25

21 Oct '25

Issue #21642 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Feature #21642: Introduce `IO::ConnectionReset` and `IO::BrokenPipe` as standardized IO-level exceptions. https://bugs.ruby-lang.org/issues/21642 * Author: ioquatix (Samuel Williams) * Status: Open ---------------------------------------- Currently, different IO implementations in Ruby raise inconsistent exception types when a connection is reset or broken. For example: ```ruby # Plain TCP socket: socket.read_nonblock(1024) # => Errno::ECONNRESET # SSL socket: ssl_socket.read_nonblock(1024) # => OpenSSL::SSL::SSLError: SSL_read: unexpected eof while reading ``` Both represent a *connection reset by peer*, but the errors differ significantly in type and message. This inconsistency makes it difficult to handle connection-level errors generically across IO types. Similarly, `EPIPE` is used in some contexts to signal a *broken connection*, but again, the representation and message differ between IO classes. ### Proposal Introduce explicit subclasses of the corresponding system errors as part of Ruby’s standard IO interface: ```ruby class IO class ConnectionReset < Errno::ECONNRESET; end class BrokenPipe < Errno::EPIPE; end end ``` Then, standardize the Ruby I/O ecosystem (including OpenSSL) to raise these subclasses instead of raw system errors or library-specific error wrappers. This would establish a consistent, well-defined public interface for handling connection-level failures. ### Motivation * **Consistency:** Users can handle `IO::ConnectionReset` across `IO`, `TCPSocket`, `OpenSSL::SSL::SSLSocket`, and other IO-like objects. * **Clarity:** The name clearly expresses a high-level semantic (“connection reset”) rather than a low-level system error. * **Extensibility:** Other Ruby IO implementations (custom sockets, pipes, etc.) can follow the same convention. * **Backwards Compatibility:** Because `IO::ConnectionReset < Errno::ECONNRESET`, existing rescue clauses continue to work: ```ruby rescue Errno::ECONNRESET # still catches it end ``` ### Examples ```ruby begin io.read_nonblock(1024) rescue IO::ConnectionReset puts "Connection was reset by peer." rescue IO::BrokenPipe puts "Connection was broken (EPIPE)." end ``` ### Impact on existing code * Minimal to none. * Existing code that rescues `Errno::ECONNRESET` or `Errno::EPIPE` will continue to function. * Future code gains a more semantic and portable way to handle these common failure modes. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:123505] [Ruby Bug#19017] Net::HTTP may block when attempting to reuse a persistent connection
by dotconfig404 (Friedrich Raschwitz) 20 Oct '25

20 Oct '25

Issue #19017 has been updated by dotconfig404 (Friedrich Raschwitz). Hi, I am not sure we should solve this in IO, the error lies more in calling eof? in the first place I would say as eof? is meant to be blocking - and currently I only see solutions that involve non-blocking calls. The solution proposed by Josh C lacks the EOF handling, I have created an issue at the appropiate module including PR, that should be fine as a workaround, but I would love it if we could issue a SSL_peek or a SSL_read with zero length to check for handshake data instead. I think that'd require a new method in the OpenSSL extension, at the very least it'd require some changes to ossl_ssl.c if we can discuss what is best here I'll gladly help implementing Maybe the issue is best fixed in the net module after all, changing the way requests are sent altogether, I am not sure. please see the issue https://github.com/ruby/net-http/issues/233 and pull request https://github.com/ruby/net-http/pull/232 ---------------------------------------- Bug #19017: Net::HTTP may block when attempting to reuse a persistent connection https://bugs.ruby-lang.org/issues/19017#change-114877 * Author: joshc (Josh C) * Status: Open * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Ruby's Net::HTTP code performs a blocking `Net::BufferedIO#eof?` check when attempting to reuse a persistent HTTP connection. See https://github.com/ruby/ruby/blob/6b099328af2ae2d04cbfd06fedc36a19cdecd30d/…. The bug is the check can hang for up to the HTTP `read_timeout`, which is 60 seconds by default. The code calls `TCPSocket#wait_readable(0)` to see if the socket is readable before calling the blocking `eof?` method. However, it's possible for the socket to be readable with SSL Handshake records and no Application Data. So the call to `eof?` will process the SSL Handshake records, but hang since no Application Data is available. The issue can be triggered if a TLS 1.3 server sends a `NewSessionTicket` sometime after Application Data is written. The attached client and server code demonstrate the problem. Note it's important that the client and server be on separate hosts otherwise `eof?` will always return immediately. On the server, copy `Server.java` and `certs.p12` into a directory, install JDK 17, compile the server and run it: ``` $ openssl pkcs12 -info -in certs.p12 -noout -passin pass:password MAC: sha1, Iteration 2048 MAC length: 20, salt length: 8 PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Certificate bag PKCS7 Data Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048 $ sudo apt install -y openjdk-17-jdk openjdk-17-jre $ javac Server.java $ java -Djavax.net.debug=ssl,verbose Server Loaded pkcs12 ``` On the client, copy `http.rb` and `ca.pem` into a directory, add the IP address for the server as `pluto` to `/etc/hosts`: ``` $ file ca.pem $ sudo vi /etc/hosts ... 192.168.0.10 pluto ... $ ruby --version ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-linux] $ openssl version OpenSSL 1.1.1f 31 Mar 2020 ``` Run the client to make the first request: ``` $ ruby http.rb opening connection to pluto:8888... opened starting SSL for pluto:8888... ``` The server will handle request_1 and trigger a new session ticket: ``` javax.net.ssl|DEBUG|10|main|2022-09-22 18:18:23.269 UTC|SSLCipher.java:466|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472 Connected to 37532 Handling request_0 ... snip ... javax.net.ssl|DEBUG|10|main|2022-09-22 18:18:25.310 UTC|SSLCipher.java:2024|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE countdown value = 137438953472 javax.net.ssl|DEBUG|10|main|2022-09-22 18:18:25.335 UTC|SSLCipher.java:1870|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE countdown value = 137438953472 read body updated session data javax.net.ssl|ALL|10|main|2022-09-22 18:18:25.343 UTC|SSLSocketImpl.java:1564|trigger new session ticket wrote response Handling request_1 ``` The client will hang when trying to reuse the persistent connection: ``` OSSL_DEBUG: SSL SESSION new callback added [ossl_ssl.c:963] SSL established, protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384 <- "POST / HTTP/1.1\r\nAccept-Encoding: identity\r\nConnection: keep-alive\r\nContent-Type: text/plain\r\nAccept: */*\r\nUser-Agent: Ruby\r\nHost: pluto:8888\r\nContent-Length: 0\r\n\r\n" <- "" OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] -> "HTTP/1.1 200 OK\r\n" -> "Content-Length: 0\r\n" -> "\r\n" reading 0 bytes... -> "" read 0 bytes Conn keep-alive OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] ``` Pressing Ctrl-C shows the backtrace: ``` ^CTraceback (most recent call last): 11: from http.rb:10:in `<main>' 10: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:933:in `start' 9: from http.rb:17:in `block in <main>' 8: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1294:in `post' 7: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1506:in `send_entity' 6: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1492:in `request' 5: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1518:in `transport_request' 4: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/http.rb:1573:in `begin_transport' 3: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/net/protocol.rb:134:in `eof?' 2: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/openssl/buffering.rb:300:in `eof?' 1: from /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/openssl/buffering.rb:57:in `fill_rbuff' /home/josh/.rbenv/versions/2.7.6/lib/ruby/2.7.0/openssl/buffering.rb:57:in `sysread': Interrupt ``` I get the same behavior with latest ruby too: ``` $ ruby --version ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] ``` Changing Net::HTTP to the following: ``` elsif @socket.io.read_nonblock(0, exception: false).nil? ``` Resolves the issue: ``` $ ruby http.rb opening connection to pluto:8888... opened starting SSL for pluto:8888... OSSL_DEBUG: SSL SESSION new callback added [ossl_ssl.c:963] SSL established, protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384 <- "POST / HTTP/1.1\r\nAccept-Encoding: identity\r\nConnection: keep-alive\r\nContent-Type: text/plain\r\nAccept: */*\r\nUser-Agent: Ruby\r\nHost: pluto:8888\r\nContent-Length: 0\r\n\r\n" <- "" OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] -> "HTTP/1.1 200 OK\r\n" -> "Content-Length: 0\r\n" -> "\r\n" reading 0 bytes... -> "" read 0 bytes Conn keep-alive <- "POST / HTTP/1.1\r\nAccept-Encoding: identity\r\nConnection: keep-alive\r\nContent-Type: text/plain\r\nAccept: */*\r\nUser-Agent: Ruby\r\nHost: pluto:8888\r\nContent-Length: 0\r\n\r\n" <- "" OSSL_DEBUG: SSL SESSION new callback entered [ossl_ssl.c:454] -> "HTTP/1.1 200 OK\r\n" -> "Content-Length: 0\r\n" -> "\r\n" reading 0 bytes... -> "" read 0 bytes Conn keep-alive ``` However, based on https://github.com/ruby/ruby/pull/1089#issuecomment-159878003 that change may not be correct. Or it could be that Ruby on Windows doesn't have this issue anymore. ---Files-------------------------------- Server.java (3.75 KB) http.rb (423 Bytes) ca.pem (8.43 KB) certs.p12 (2.24 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:123498] [Ruby Bug#21643] 'make' or 'make up' results in: uncommon.mk:1988: *** missing separator. Stop.
by duerst 20 Oct '25

20 Oct '25

Issue #21643 has been reported by duerst (Martin Dürst). ---------------------------------------- Bug #21643: 'make' or 'make up' results in: uncommon.mk:1988: *** missing separator. Stop. https://bugs.ruby-lang.org/issues/21643 * Author: duerst (Martin Dürst) * Status: Open * ruby -v: ruby 3.0.2p107 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I tried to get my ruby checkout up to date using 'make up', but after a lot of output, it stopped with the message "uncommon.mk:1988: *** missing separator. Stop.". Now it just gives this message when trying 'make up' or 'make'. Line 1988 and 1989 (the last two lines) in upcommon.mk read: ``` !include $(srcdir)/prism/srcs.mk !include $(srcdir)/depend ``` This happens on a WSI Ubuntu with GNU Make 4.3. Any help appreciated! -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111742] [Ruby master Feature#19326] Please add a better API for passing a Proc to a Ractor
by sdwolfz 18 Oct '25

18 Oct '25

Issue #19326 has been reported by sdwolfz (Codruț Gușoi). ---------------------------------------- Feature #19326: Please add a better API for passing a Proc to a Ractor https://bugs.ruby-lang.org/issues/19326 * Author: sdwolfz (Codruț Gușoi) * Status: Open * Priority: Normal ---------------------------------------- Example 1: ```ruby class Worker def initialize(&block) @block = block end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:271:in `new': allocator undefined for Proc (TypeError) from scripts/run.rb:9:in `run' from scripts/run.rb:14:in `<main>' ``` Example 2: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Worker.new { 1 } puts worker.run.take ``` Errors with: ``` <internal:ractor>:820:in `make_shareable': Proc's self is not shareable: #<Proc:0x00007f00394c38b8 scripts/run.rb:13> (Ractor::IsolationError) from scripts/run.rb:5:in `initialize' from scripts/run.rb:13:in `new' from scripts/run.rb:13:in `<main>' ``` Example 3: ```ruby class Worker def initialize(&block) @block = Ractor.make_shareable(block) end def run Ractor.new(@block, &:call) end end worker = Ractor.current.instance_eval { Worker.new { 1 } } puts worker.run.take ``` Works, but having `Ractor.current.instance_eval` as a wrapper around the block is not ideal, as Ractor is supposed to be only an implementation detail in Worker. I know about https://bugs.ruby-lang.org/issues/18243 and the discussion around `proc.bind(nil)`. That would actually be ideal, as for the purposes if why I want this functionality I don't care what `self` is in a block, and the less it has access to the better. The general idea is to have a Ractor be able to lazily execute an arbitrary proc. And all the bindings it would need would be passed explicitly, either through `args` in the constructor or through `send`/`receive`, so `self` would really not matter. The benefit: this would make it so concurrent code can be more easily be implemented with Ractors as currently you can execute an arbitrary proc by passing it to a Thread (but you don't get the nice data isolation). -- https://bugs.ruby-lang.org/

6 12

[ruby-core:123446] [Ruby Bug#21632] Backport REXML CVE-2025-58767 fix
by Bo98 (Bo Anderson) 17 Oct '25

17 Oct '25

Issue #21632 has been reported by Bo98 (Bo Anderson). ---------------------------------------- Bug #21632: Backport REXML CVE-2025-58767 fix https://bugs.ruby-lang.org/issues/21632 * Author: Bo98 (Bo Anderson) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Even though it's a bundled gem and not a default gem, it would be worthwhile backporting the fix for CVE-2025-58767 (https://www.ruby-lang.org/en/news/2025/09/18/dos-rexml-cve-2025-58767/) Ruby 3.4 PR: https://github.com/ruby/ruby/pull/14795 Ruby 3.3 PR: https://github.com/ruby/ruby/pull/14796 I'm not sure what to do for Ruby 3.2. It's a security fix so it qualifies for a backport, but there's other changes included in a version bump. Do we need a rexml 3.3.9.1? -- https://bugs.ruby-lang.org/

2 2

[ruby-core:123489] [Ruby Bug#21641] Hash#to_s behaves different in 3.4
by matheussilvasantos (Matheus Oliveira) 17 Oct '25

17 Oct '25

Issue #21641 has been reported by matheussilvasantos (Matheus Oliveira). ---------------------------------------- Bug #21641: Hash#to_s behaves different in 3.4 https://bugs.ruby-lang.org/issues/21641 * Author: matheussilvasantos (Matheus Oliveira) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- I couldn't find anywhere documenting this change from Ruby 3.3 to Ruby 3.4: 3.3.9: ``` ruby > irb 3.3.9 :001 > {x:1}.to_s => "{:x=>1}" 3.3.9 :002 > ``` 3.4.0: ```ruby 3.4.0 :001 > {x:1}.to_s => "{x: 1}" 3.4.0 :002 > ``` Is there a way to continue with the old behaviour - flag to compilation, monkey patch, etc.? Unfortunately, the application I'm working on stores the `to_s` in Redis and use it later; if the result doesn't match for the same Hash, it would break a few things. -- https://bugs.ruby-lang.org/

4 3