January 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:112066] [Ruby master Bug#18567] Depending on default gems in stdlib gems when not needed considered harmful
by hsbt (Hiroshi SHIBATA) 27 Jan '23

27 Jan '23

Issue #18567 has been updated by hsbt (Hiroshi SHIBATA). I don't agree it. I can help default/bundled gems are working with JRuby/TruffleRuby like: * https://github.com/ruby/date/issues/48 * https://github.com/ruby/bigdecimal/issues/169 Please file your issue each repositories like above issues. ---------------------------------------- Bug #18567: Depending on default gems in stdlib gems when not needed considered harmful https://bugs.ruby-lang.org/issues/18567#change-101500 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- CRuby over time moves more and more code to default gems, to bundled gems and or even stops shipping some gems which used to be stdlibs (#5481). I believe the main motivation for that is being to fix security issues without needing to make a CRuby release, and that makes sense. There are however multiple unwanted side effects of this: 1. Removing gems from stdlib (e.g., #17873) is a breaking change, which makes upgrading to a new Ruby version more difficult. I think this should only be done if there is a clear gain. Being a default gem is already enough to fix a security issue without a CRuby release. 2. When any gem depends on a default gem, it tends to break on all Ruby implementations except CRuby, and for older Ruby versions. Let's focus on this second point. There can be good reasons to depend on a specific version (or ~>/>=) of a default gem, for instance to ensure a given security issue is addressed. In other cases, I think there is no value to depend explicitly on a default gem, it would work without an explicit dependency since it is still "in stdlib". And it is actually harmful to depend on default gems for JRuby, TruffleRuby and older Ruby versions, because the default gem does typically not work there yet, but the stdlib works just fine! The reason for that is simple, those gems used to be stdlib and so were implemented directly in the Ruby implementation. Also depending on default gem will typically be redundant with what's in stdlib, which is then a waste of network, time and disk. For larger default gems (e.g., openssl), I believe the solution is those gems to support JRuby, TruffleRuby, etc. This is useful so the behavior for a given version of the gem is compatible between Ruby implementations, has the same security fixes, etc. It is however a large effort and overhead to do this, and it only makes sense if people are going to need to depend on such a gem explicitly (either for security or new features in a given version), otherwise the version in stdlib is good enough and much simpler. Here are I think some clear cases of default gems which are clearly more overhead than what they gain: * io-wait: just a few methods very tight to IO internals, should really be core * io-nonblock just a few methods very tight to IO internals, should really be core * digest: has a public header and so versioning it doesn't work. Also it makes sense to reuse e.g. MessageDigest on JVM for better performance. * strscan: this accesses a lot of Regexp internal, it would fit better in each implementation repo as a non-gem stdlib. These are all small, they are all fairly stable, and it's unclear why they are even default gems in the first place. They also seem fairly unlikely to have security issues. So this is what I propose: * Do not depend on default gems in stdlib gems unless necessary (for security or feature), or unless we know the next version of Ruby will no longer ship that gem. An example is `net-protocol` depending needlessly on `io-wait`, I'll make a PR for that. * I think those gems listed just above should no longer be default gems in the future to clarify the situation. They should either be core or regular non-gem stdlib. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112057] [Ruby master Bug#19382] Infinite loop in tracepoints where called method comes from evaled code
by luke-gru (Luke Gruber) 26 Jan '23

26 Jan '23

Issue #19382 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19382: Infinite loop in tracepoints where called method comes from evaled code https://bugs.ruby-lang.org/issues/19382 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby events = [] meth_name = "mymethod" code = <<~RUBY def #{meth_name}(); true; end RUBY eval(code, binding, 'my_location') tracepoint = TracePoint.new(:line) { |tp| events << tp.path # infinite loop here }.tap(&:enable) send("#{meth_name}") pp events ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:112060] [Ruby master Bug#19384] ASCII 128..154 characters in IO.popen or %x output do not reflect the proper encoding in Windows
by stringsn88keys (Thomas Powell) 26 Jan '23

26 Jan '23

Issue #19384 has been reported by stringsn88keys (Thomas Powell). ---------------------------------------- Bug #19384: ASCII 128..154 characters in IO.popen or %x output do not reflect the proper encoding in Windows https://bugs.ruby-lang.org/issues/19384 * Author: stringsn88keys (Thomas Powell) * Status: Open * Priority: Normal * ruby -v: 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Operating systems: Windows 10 and Windows Server 2022 (likely all recent versions of Windows) Ruby: confirmed on 2.7.7 through 3.1.3 On macOS and Linux I can create a file named "ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜ" and then do a directory listing via IO.popen or %x and find the file name in the output string. In Windows, while the encoding is reported as #<Encoding:UTF-8>, I have to .force_encoding on the output to be able to find the string in the output: %x|dir tmp| ----------- output encoding: #<Encoding:UTF-8> Output can be made to match by forcing the following encodings: IBM437 CP850 IBM865 IO.popen(dir tmp).read ---------------------- output encoding: #<Encoding:UTF-8> Output can be made to match by forcing the following encodings: IBM437 CP850 IBM865 But on macOS or Linux: ❯ ruby directory_test.rb %x|ls tmp| ---------- output encoding: #<Encoding:UTF-8> output matches without forcing encoding Output can be made to match by forcing the following encodings: UTF-8 UTF8-MAC CESU-8 UTF8-DoCoMo UTF8-KDDI UTF8-SoftBank IO.popen(ls tmp).read --------------------- output encoding: #<Encoding:UTF-8> output matches without forcing encoding Output can be made to match by forcing the following encodings: UTF-8 UTF8-MAC CESU-8 UTF8-DoCoMo UTF8-KDDI UTF8-SoftBank Note: The example is contrived because the actual IO.popen output is from a customer system with umlaut characters. However, I have found creating a filename with these characters will adequately reproduce the issue. Also, I'm only using ASCII/IBM437 as an encoding to create a contiguous set of characters, "ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜ" as a contrived example. ---Files-------------------------------- directory_test.rb (1.14 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112050] [Ruby master Bug#18567] Depending on default gems in stdlib gems when not needed considered harmful
by Eregon (Benoit Daloze) 26 Jan '23

26 Jan '23

Issue #18567 has been updated by Eregon (Benoit Daloze). @hsbt https://bugs.ruby-lang.org/issues/18567#note-30 is what is needed for future default/bundled gems. Do you agree to it? ---------------------------------------- Bug #18567: Depending on default gems in stdlib gems when not needed considered harmful https://bugs.ruby-lang.org/issues/18567#change-101487 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- CRuby over time moves more and more code to default gems, to bundled gems and or even stops shipping some gems which used to be stdlibs (#5481). I believe the main motivation for that is being to fix security issues without needing to make a CRuby release, and that makes sense. There are however multiple unwanted side effects of this: 1. Removing gems from stdlib (e.g., #17873) is a breaking change, which makes upgrading to a new Ruby version more difficult. I think this should only be done if there is a clear gain. Being a default gem is already enough to fix a security issue without a CRuby release. 2. When any gem depends on a default gem, it tends to break on all Ruby implementations except CRuby, and for older Ruby versions. Let's focus on this second point. There can be good reasons to depend on a specific version (or ~>/>=) of a default gem, for instance to ensure a given security issue is addressed. In other cases, I think there is no value to depend explicitly on a default gem, it would work without an explicit dependency since it is still "in stdlib". And it is actually harmful to depend on default gems for JRuby, TruffleRuby and older Ruby versions, because the default gem does typically not work there yet, but the stdlib works just fine! The reason for that is simple, those gems used to be stdlib and so were implemented directly in the Ruby implementation. Also depending on default gem will typically be redundant with what's in stdlib, which is then a waste of network, time and disk. For larger default gems (e.g., openssl), I believe the solution is those gems to support JRuby, TruffleRuby, etc. This is useful so the behavior for a given version of the gem is compatible between Ruby implementations, has the same security fixes, etc. It is however a large effort and overhead to do this, and it only makes sense if people are going to need to depend on such a gem explicitly (either for security or new features in a given version), otherwise the version in stdlib is good enough and much simpler. Here are I think some clear cases of default gems which are clearly more overhead than what they gain: * io-wait: just a few methods very tight to IO internals, should really be core * io-nonblock just a few methods very tight to IO internals, should really be core * digest: has a public header and so versioning it doesn't work. Also it makes sense to reuse e.g. MessageDigest on JVM for better performance. * strscan: this accesses a lot of Regexp internal, it would fit better in each implementation repo as a non-gem stdlib. These are all small, they are all fairly stable, and it's unclear why they are even default gems in the first place. They also seem fairly unlikely to have security issues. So this is what I propose: * Do not depend on default gems in stdlib gems unless necessary (for security or feature), or unless we know the next version of Ruby will no longer ship that gem. An example is `net-protocol` depending needlessly on `io-wait`, I'll make a PR for that. * I think those gems listed just above should no longer be default gems in the future to clarify the situation. They should either be core or regular non-gem stdlib. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112046] [Ruby master Bug#18567] Depending on default gems in stdlib gems when not needed considered harmful
by hsbt (Hiroshi SHIBATA) 26 Jan '23

26 Jan '23

Issue #18567 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed All PRs of https://bugs.ruby-lang.org/issues/18567#note-5 have been closed. There is no action now. ---------------------------------------- Bug #18567: Depending on default gems in stdlib gems when not needed considered harmful https://bugs.ruby-lang.org/issues/18567#change-101483 * Author: Eregon (Benoit Daloze) * Status: Closed * Priority: Normal * Assignee: hsbt (Hiroshi SHIBATA) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- CRuby over time moves more and more code to default gems, to bundled gems and or even stops shipping some gems which used to be stdlibs (#5481). I believe the main motivation for that is being to fix security issues without needing to make a CRuby release, and that makes sense. There are however multiple unwanted side effects of this: 1. Removing gems from stdlib (e.g., #17873) is a breaking change, which makes upgrading to a new Ruby version more difficult. I think this should only be done if there is a clear gain. Being a default gem is already enough to fix a security issue without a CRuby release. 2. When any gem depends on a default gem, it tends to break on all Ruby implementations except CRuby, and for older Ruby versions. Let's focus on this second point. There can be good reasons to depend on a specific version (or ~>/>=) of a default gem, for instance to ensure a given security issue is addressed. In other cases, I think there is no value to depend explicitly on a default gem, it would work without an explicit dependency since it is still "in stdlib". And it is actually harmful to depend on default gems for JRuby, TruffleRuby and older Ruby versions, because the default gem does typically not work there yet, but the stdlib works just fine! The reason for that is simple, those gems used to be stdlib and so were implemented directly in the Ruby implementation. Also depending on default gem will typically be redundant with what's in stdlib, which is then a waste of network, time and disk. For larger default gems (e.g., openssl), I believe the solution is those gems to support JRuby, TruffleRuby, etc. This is useful so the behavior for a given version of the gem is compatible between Ruby implementations, has the same security fixes, etc. It is however a large effort and overhead to do this, and it only makes sense if people are going to need to depend on such a gem explicitly (either for security or new features in a given version), otherwise the version in stdlib is good enough and much simpler. Here are I think some clear cases of default gems which are clearly more overhead than what they gain: * io-wait: just a few methods very tight to IO internals, should really be core * io-nonblock just a few methods very tight to IO internals, should really be core * digest: has a public header and so versioning it doesn't work. Also it makes sense to reuse e.g. MessageDigest on JVM for better performance. * strscan: this accesses a lot of Regexp internal, it would fit better in each implementation repo as a non-gem stdlib. These are all small, they are all fairly stable, and it's unclear why they are even default gems in the first place. They also seem fairly unlikely to have security issues. So this is what I propose: * Do not depend on default gems in stdlib gems unless necessary (for security or feature), or unless we know the next version of Ruby will no longer ship that gem. An example is `net-protocol` depending needlessly on `io-wait`, I'll make a PR for that. * I think those gems listed just above should no longer be default gems in the future to clarify the situation. They should either be core or regular non-gem stdlib. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112043] [Ruby master Bug#19112] Ractor garbage collection breaks/disables all active tracepoints
by luke-gru (Luke Gruber) 25 Jan '23

25 Jan '23

Issue #19112 has been updated by luke-gru (Luke Gruber). Pull request is here if you're interested: https://github.com/ruby/ruby/pull/7184 ---------------------------------------- Bug #19112: Ractor garbage collection breaks/disables all active tracepoints https://bugs.ruby-lang.org/issues/19112#change-101477 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0dev (2022-11-08T08:08:48Z master cdb3ec3af8) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the `ddtrace` gem](https://github.com/DataDog/dd-trace-rb) and I found an issue with Ractors + TracePoint. ### Background For tracking time spent in Garbage Collection on our Ruby profiler, we use a tracepoint that listens to the internal GC events. While doing other experiments around Ractors and profiling, I noticed that our tracepoint would suddenly stop working after Ractors were used in the application. I was able to reduce this down to the testcase below. ### How to reproduce (Ruby version & script) I was able to reproduce this on any Ruby 3 version, including master (`ruby 3.2.0dev (2022-11-08T08:08:48Z master cdb3ec3af8) [x86_64-linux]`). ```ruby puts RUBY_DESCRIPTION if ENV['RUN_RACTOR'] == 'true' Ractor.new { 10 }.take puts "Ractor ran!" else puts "Ractor DID NOT ran!" end puts "Enabling tracepoint" tracepoint = TracePoint.new(:line) { |tp| p [tp.path, tp.lineno, tp.event] }.tap(&:enable) 5.times { puts "Triggering gc!"; GC.start } puts "Tracepoint state is enabled? #{tracepoint.enabled?}" puts "Re-enabling tracepoint" tracepoint.enable puts "Finished!" ``` ### Expectation and result Without the Ractor, the tracepoint works as intended: ``` # RUN_RACTOR=false ./ruby ../ruby-3.1.2/triggergc.rb ruby 3.2.0dev (2022-11-08T08:08:48Z master cdb3ec3af8) [x86_64-linux] Ractor DID NOT ran! Enabling tracepoint ["<internal:kernel>", 91, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] ["../ruby-3.1.2/triggergc.rb", 16, :line] ["<internal:trace_point>", 257, :line] Tracepoint state is enabled? true ["../ruby-3.1.2/triggergc.rb", 17, :line] Re-enabling tracepoint ["../ruby-3.1.2/triggergc.rb", 18, :line] ["<internal:trace_point>", 213, :line] ["../ruby-3.1.2/triggergc.rb", 20, :line] ["../ruby-3.1.2/triggergc.rb", 20, :line] Finished! ``` ...but once the Ractor runs and is garbage collected, we see that the tracepoint breaks: ``` # RUN_RACTOR=true ./ruby ../ruby-3.1.2/triggergc.rb ruby 3.2.0dev (2022-11-08T08:08:48Z master cdb3ec3af8) [x86_64-linux] ../ruby-3.1.2/triggergc.rb:5: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. Ractor ran! Enabling tracepoint ["<internal:kernel>", 91, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] ["../ruby-3.1.2/triggergc.rb", 14, :line] Triggering gc! ["<internal:gc>", 34, :line] Triggering gc! Triggering gc! Triggering gc! Triggering gc! Tracepoint state is enabled? true Re-enabling tracepoint ["../ruby-3.1.2/triggergc.rb", 20, :line] ["../ruby-3.1.2/triggergc.rb", 20, :line] Finished ``` ### Additional notes This is a somewhat annoying bug, because it can break all gems that use tracepoints, including `ddtrace`. In particular for `ddtrace`, our plan is to disable the feature that uses tracepoints for Ruby 3 users, to avoid any issues from our tracepoints getting disabled. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111950] [Ruby master Bug#19360] Enabling coverage with `-r` option isn't sufficient to intercept top level script.
by ioquatix (Samuel Williams) 25 Jan '23

25 Jan '23

Issue #19360 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #19360: Enabling coverage with `-r` option isn't sufficient to intercept top level script. https://bugs.ruby-lang.org/issues/19360 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- For some reason, Ruby's coverage library doesn't work when the file is loaded from the command line. In the below example, test2.rb loads test.rb. If you run test2.rb with coverage enabled, it will report coverage for test.rb but not test2.rb. If you run test.rb directly, no coverage is reported. ``` samuel@aiko ~/P/i/autocoverage> ruby -r "./autocoverage.rb" test.rb Hello World {} samuel@aiko ~/P/i/autocoverage> ruby -r "./autocoverage.rb" test2.rb Hello World {"/home/samuel/Projects/ioquatix/autocoverage/test.rb"=>{:lines=>[1, 1, nil, nil, 1], :branches=>{}, :methods=>{[Object, :main, 1, 0, 3, 3]=>1}}} ``` The same problem affects simplecov. ``` ruby -r "./simplecov.rb" test.rb ... similar results in coverage directory ... ``` See https://github.com/ioquatix/autocoverage for a complete reproduction. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:112038] [Ruby master Bug#19376] Ability to read ivars of non-frozen classes/modules across ractors is not thread-safe
by luke-gru (Luke Gruber) 25 Jan '23

25 Jan '23

Issue #19376 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #19376: Ability to read ivars of non-frozen classes/modules across ractors is not thread-safe https://bugs.ruby-lang.org/issues/19376 * Author: luke-gru (Luke Gruber) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This segfaults: ```ruby class C class << self attr_accessor :val end end GO = false rs = 100.times.map do Ractor.new do Thread.pass until GO 1000.times do val = C.val p val end end end ts = 100.times.map do |i| Thread.new do Thread.pass until GO 1000.times do C.val = Object.new.freeze end end end GO = true ts.each(&:join) rs.each(&:take) ``` It looks like a silly example, but it can crash even if the main thread doesn't spawn any more threads. Getting/setting ivars on objects in parallel without VM lock isn't safe, so for non-frozen shareable objects (basically classes and modules), it's unsafe to access their instance variables even if the values are shareable. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:112037] [Ruby master Feature#15778] Expose an API to pry-open the stack frames in Ruby
by st0012 (Stan Lo) 25 Jan '23

25 Jan '23

Issue #15778 has been updated by st0012 (Stan Lo). > What if we settle for an API and implement and test it first in the debug gem? The `debug` gem already has a method `DEBUGGER__.capture_frames` that achieves something similar. But I agree with @Eregon on not using the `debug` gem for this: - Pulling the `debug` gem in means this the API won't be used and shaped for production use. - The `debug` gem causes side-effects upon required (e.g. new threads and TracePoints activated in the background). In some cases it changes applications' behaviours and breaks tests for example. You can see more related discussions in [this issue](https://github.com/ruby/debug/issues/797). - It's probably not a huge risk for most apps, but this is something we should avoid when possible. - Even without all these issues, it complicates `debug` gem's role and could complicate its maintenance. I know the proposal is just to experiment it in `debug` first, but the reality is that we can't make gems move away from a dependency easily. ---------------------------------------- Feature #15778: Expose an API to pry-open the stack frames in Ruby https://bugs.ruby-lang.org/issues/15778#change-101471 * Author: gsamokovarov (Genadi Samokovarov) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) ---------------------------------------- Hello, I'm the maintainer of the web-console (https://github.com/rails/web-console/) gem, where one of our features is to jump between the frames in which an error occurred. To accomplish this, I currently use the Debug Inspector CRuby API. I think we should expose this functionality in Rubyland, so tools like web-console don't need to resort to C code for this. This also makes it quite harder for me to support different implementations like JRuby or TruffleRuby as everyone is having a different way to create Ruby Binding objects that represent the frames. Here the API ideas: Add `Thread::Backtrace::Location#binding` method that can create a binding for a specific caller of the current frame. We can reuse the existing `Kernel.caller_locations` method to generate the array of `Thread::Backtrace::Location` objects. We can optionally have the `Kernel.caller_locations(debug: true)` argument if we cannot generate the bindings lazily on the VM that can instruct the VM to do the slower operation. - `Thread::Backtrace::Location#binding` returns `Binding|nil`. Nil result may mean that the current location is a C frame or a JITted/optimized frame and we cannot debug it. We can also expose the DebugInspector API directly, as done in the https://github.com/banister/debug_inspector gem, but for tools like web-console, we'd need to map the bindings with the backtrace, as we cannot generate Bindings for every frame (C frames) and this needs to be done in application code, so I think the `Thread::Backtrace::Location#binding` is the better API for Ruby-land. Such API can help us eventually write most of our debuggers in Ruby as right now we don't have a way to do Post-Mortem debugging without native code or even start our debuggers without monkey-patching `Binding`. I have presented this idea in a RubyKaigi's 2019 talk called "Writing Debuggers in Plain Ruby", you can check-out the slides for more context: http://kaigi-debuggers-in-ruby.herokuapp.com. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111872] [Ruby master Bug#19350] Backport the latest stable version of RubyGems/Bundler
by hsbt (Hiroshi SHIBATA) 25 Jan '23

25 Jan '23

Issue #19350 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19350: Backport the latest stable version of RubyGems/Bundler https://bugs.ruby-lang.org/issues/19350 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Priority: Normal * Assignee: naruse (Yui NARUSE) * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- RubyGems 3.4.4 and Bundler 2.4.4 have been released. We should backport them into `ruby_3_2` branch. https://github.com/ruby/ruby/pull/7061 I also added patch for [Bug #19298] to above pull-request. -- https://bugs.ruby-lang.org/

2 2