- ruby-core - ml.ruby-lang.org

[ruby-core:116299] [Ruby master Feature#16495] Inconsistent quotes in error messages
by Eregon (Benoit Daloze) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by Eregon (Benoit Daloze). Great to see progress on this issue. Agreed, for method names and file names, single quotes are best. Backticks are best for quoting source code, and there is no source code in Ruby backtraces. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106321 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116298] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by Eregon (Benoit Daloze) 18 Jan '24

18 Jan '24

Issue #18576 has been updated by Eregon (Benoit Daloze). I think everyone's opinion on the thread is pretty clear and not everyone agrees, that's fine. @matz Could you decide whether it's OK to experiment with the Encoding#name changing to "BINARY" or not? If not, is @byroot's proposal in https://bugs.ruby-lang.org/issues/18576#note-33 accepted? ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106320 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116296] [Ruby master Feature#16495] Inconsistent quotes in error messages
by Dan0042 (Daniel DeLorme) 18 Jan '24

18 Jan '24

Issue #16495 has been updated by Dan0042 (Daniel DeLorme). I'd like something that's convenient to copy-paste. Testing: with single quote pair: undefined local variable or method 'foobar' for main:Object (NameError) `undefined local variable or method 'foobar' for main:Object (NameError)` ``undefined local variable or method 'foobar' for main:Object (NameError)`` with backtick pair: undefined local variable or method `foobar` for main:Object (NameError) `undefined local variable or method `foobar` for main:Object (NameError)` ``undefined local variable or method `foobar` for main:Object (NameError)`` At first I preferred backticks but given how the above are rendered in markdown I've ended up preferring single quotes. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106318 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116295] [Ruby master Feature#16495] Inconsistent quotes in error messages
by matz (Yukihiro Matsumoto) 17 Jan '24

17 Jan '24

Issue #16495 has been updated by matz (Yukihiro Matsumoto). I agree with giving up backquotes. I'd rather use single quote pairs, unless any compatibility issues are caused. Matz. ---------------------------------------- Feature #16495: Inconsistent quotes in error messages https://bugs.ruby-lang.org/issues/16495#change-106317 * Author: Kolano (Kenneth Kolano) * Status: Open * Priority: Normal * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Error messages use inconsistent pairs of quotes, for instance: ``` -e:1:in `<main>': undefined local variable or method `foo' for main:Object (NameError) ``` where a back tick is used on the left-hand side, and a single quote is used on the right. The same quotes should be used on either side of the elements being quoted. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116134] [Ruby master Bug#20174] Ruby 3.2 jit_cont_free segfault with YJIT enabled
by ziggythehamster (Keith Gable) 17 Jan '24

17 Jan '24

Issue #20174 has been reported by ziggythehamster (Keith Gable). ---------------------------------------- Bug #20174: Ruby 3.2 jit_cont_free segfault with YJIT enabled https://bugs.ruby-lang.org/issues/20174 * Author: ziggythehamster (Keith Gable) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Ruby 3.2 segfaults reproducibly for us on aarch64 (Graviton2) and x86_64 with YJIT enabled ... however all of my attempts to make a minimal reproducible test case have failed. The control frame of the segfault isn't consistent, but the C backtrace is. It doesn't occur in 3.3, so I used the backtrace to find the function (jit_cont_free) and compare it between 3.2 and 3.3. The only change that seemed like a plausible candidate was a one-line guard added by k0kubun in e07e9f8491d9ab8b22d2bdf6a8aeba834dac7eef, so I added .patch to the end of the URL on GitHub and added that as a patch against 3.2. This resolved the problem. I would therefore suggest backporting that change from 3.3 to 3.2 :). The change that triggered this is a two line change to a gemspec (that we need to refactor) that we made because Rake released a new version, which I will censor and annotate below: ``` # frozen_string_literal: true $LOAD_PATH.push File.expand_path('lib', __dir__) require 'rubygems/dependency_installer' # before: Gem::DependencyInstaller.new.install(Gem::Dependency.new('rake')) # after: Gem::DependencyInstaller.new.install(Gem::Dependency.new('rake', '~> 13.1.0')) require 'rake/file_list' Gem::Specification.new do |spec| spec.name = 'censored' spec.version = '0.0.1.pre' spec.author = 'censored' spec.email = 'censored' spec.summary = 'censored' spec.description = 'censored' spec.homepage = 'censored' spec.license = 'All rights reserved' spec.required_ruby_version = '>= 2.6.0' spec.metadata['homepage_uri'] = spec.homepage gitignore = File.read('.gitignore').lines.reject { |l| l.match?(/\A\s*#/) || l.match?(/\A\s*\z/) }.map(&:chomp) spec.files = Rake::FileList.new('\.[a-zA-Z0-9]*', '\.[a-zA-Z0-9]*/*', '**/*') .exclude(gitignore) .reject { |f| File.directory?(f) || f.match(%r{\A(test|spec|features|vendor|.git|.bundle)/}) } to_include = gitignore.select { |l| l.match?(/\A\s*!/) }.map { |l| l.delete_prefix('!') } spec.files += Rake::FileList.new(to_include).reject { |f| File.directory?(f) } spec.require_paths = ['lib'] spec.add_development_dependency 'awesome_print', '~> 1.8.0' spec.add_development_dependency 'pry', '~> 0.14.2' # before: spec.add_development_dependency 'rake', '~> 13.0.1' # after: spec.add_development_dependency 'rake', '~> 13.1.0' spec.add_development_dependency 'rdoc', '~> 6.3.1' spec.add_development_dependency 'rspec', '~> 3.11.0' spec.add_development_dependency 'rspec_junit_formatter', '~> 0.5.1' spec.add_development_dependency 'rubocop', '~> 1.39.0' spec.add_development_dependency 'rubocop-packaging', '~> 0.5.2' spec.add_development_dependency 'rubocop-rake', '~> 0.6.0' spec.add_development_dependency 'rubocop-rspec', '~> 2.12.1' spec.add_development_dependency 'simplecov', '~> 0.21.2' spec.add_development_dependency 'simplecov-cobertura', '~> 2.1.0' spec.add_development_dependency 'yard', '~> 0.9.25' spec.add_runtime_dependency 'activesupport', '>= 5.1.7', '< 8' spec.add_runtime_dependency 'censored-m', '~> 0.1.72' spec.add_runtime_dependency 'censored-r', '~> 0.1.175' spec.add_runtime_dependency 'aws-sdk-athena', '~> 1.43' spec.add_runtime_dependency 'aws-sdk-cloudwatch', '~> 1.5' spec.add_runtime_dependency 'aws-sdk-core', '~> 3.122' spec.add_runtime_dependency 'aws-sdk-dynamodb', '~> 1.5' spec.add_runtime_dependency 'aws-sdk-firehose', '~> 1.1' spec.add_runtime_dependency 'aws-sdk-glue', '~> 1.108' spec.add_runtime_dependency 'aws-sdk-kinesis', '~> 1.13' spec.add_runtime_dependency 'aws-sdk-redshift', '~> 1.2' spec.add_runtime_dependency 'aws-sdk-s3', '~> 1.9' spec.add_runtime_dependency 'aws-sdk-sns', '~> 1.3' spec.add_runtime_dependency 'aws-sdk-sqs', '~> 1.3' spec.add_runtime_dependency 'aws-sdk-ssm', '~> 1.76' spec.add_runtime_dependency 'concurrent-ruby', '>= 1.1.5' spec.add_runtime_dependency 'dry-configurable', '~> 0.13' end ``` However, I cannot turn this gemspec into a reproducer on my end. The smallest change makes the segfault go away. To avoid a gigantic issue description, I have attached the censored segfault backtraces and the RbConfig from the x86_64 build (since I'm compiling my own Ruby). I'll note again that while aarch64 and x86_64 appear to have failed while doing something in optparse this time, it appears random (or more likely: GC pressure related). I've also seen it fail when doing a require_relative much earlier. It always fails with the same C backtrace. I have absolutely no idea why `cont` might be NULL. The backtrace shows it is called by `cont_free`, which has a `VM_ASSERT` for detecting this condition. Obviously, there must be some situation where jit_cont becomes NULL due to YJIT, but I have no idea what that situation is. In case someone thinks this might be compiler/compiler option related, I am using the following: * Amazon Linux 2 * LLVM/Clang 11 except that because Amazon Linux doesn't ship lld, we are using `gcc10-ld.gold` as the linker * rustc 1.68.2 (9eb3afe9e 2023-03-27) (Amazon Linux 1.68.2-1.amzn2.0.3) * OpenSSL 3.0.12 (self-compiled with corp-dictated hardened configuration options ... I can share if someone thinks this is relevant) * `extra_warnflags="-Wno-address-of-packed-member -Wno-declaration-after-statement -Wno-register"` * aarch64: `optflags="-O3 -mcpu=neoverse-n1"` * x86_64: `optflags="-O3 -march=sandybridge"` ---Files-------------------------------- bt_aarch64.txt (34.5 KB) bt_x86_64.txt (30.3 KB) rbconfig_x86_64.txt (9.36 KB) -- https://bugs.ruby-lang.org/

3 4

[ruby-core:115594] [Ruby master Bug#20042] ObjectSpace finalizer can cause segfault
by ioquatix (Samuel Williams) 17 Jan '24

17 Jan '24

Issue #20042 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #20042: ObjectSpace finalizer can cause segfault https://bugs.ruby-lang.org/issues/20042 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ```ruby class Finalizer def call # <- missing (id) argument end end object = Object.new ObjectSpace.define_finalizer(object, Finalizer.new) object = nil GC.start # segfaults here ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:116280] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by Dan0042 (Daniel DeLorme) 17 Jan '24

17 Jan '24

Issue #18576 has been updated by Dan0042 (Daniel DeLorme). tenderlovemaking (Aaron Patterson) wrote in #note-7: > I think this example should raise an exception: > > ```ruby > u = (b = "abcde".force_encoding('ASCII-8BIT')).encode('UTF-8') > ``` I'm worried about the above misconception. No, this example shouldn't raise an exception, because being ascii-compatible is the entire reason there's "ASCII" in "ASCII-8BIT". If even @tenderlovemaking can have this misconception, I would wager it's a fairly common one. And if the encoding was renamed to "BINARY" it would further encourage the misconception. We'd wind up with a kind of Frankenstein encoding that pretends to be true binary by its name, but having the behavior of ascii-compatible encodings. This thread has several people currently agreeing that the ascii-compatible behavior should not change, but if the name was changed I can easily predict some people will call for a change in behavior because the name "binary" has that overtone. zverok (Victor Shepelev) wrote in #note-34: > For better or worse, we break compatibility constantly. > One of the recent telling examples was the removal of `File.exists?` I won't say we can never break compatibility, but there's a very big qualitative difference here. If you run into `File.exists?`, the program simply crashes with NoMethodError. If you run into `enc.name == "ASCII-8BIT"` the return value changes from true to false; the program may crash later or not, the bug can remain undetected for a long time, there's a potential for corrupted data. This is 2-3 orders of magnitude harder to debug than NoMethodError. Even if not many people are affected by this, it's a very nasty kind of incompatibility. byroot (Jean Boussier) wrote in #note-15: > We could keep `Encoding#name` as `"ASCII-8BIT"`, but change `Encoding#inspect` and make sure `EncodingError` use the `BINARY` name in its error messages. I would really like that. ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106302 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116277] [Ruby master Bug#5179] Complex#rationalize and to_r with approximate zeros
by mrkn (Kenta Murata) 17 Jan '24

17 Jan '24

Issue #5179 has been updated by mrkn (Kenta Murata). I'm working on to_r at https://github.com/ruby/ruby/pull/9581. I will do other methods later. ---------------------------------------- Bug #5179: Complex#rationalize and to_r with approximate zeros https://bugs.ruby-lang.org/issues/5179#change-106299 * Author: marcandre (Marc-Andre Lafortune) * Status: Assigned * Priority: Normal * Assignee: mrkn (Kenta Murata) * ruby -v: r32354 ---------------------------------------- Currently, Complex#rationalize and Complex#to_r raise a RangeError if the imaginary part is nonzero *or is a Float*. Note that a BigDecimal(0) is accepted, though: Complex(1, 0).to_r # => Rational(1,1) Complex(1, BigDecimal("0.0")).to_r # => Rational(1,1) Complex(1, 0.0).to_r # => RangeError This is inconsistent. I recommend not raising an error for 0.0 (Float or BigDecimal). Any objection? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115830] [Ruby master Misc#20075] DevMeeting-2024-01-17
by mame (Yusuke Endoh) 17 Jan '24

17 Jan '24

Issue #20075 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #20075: DevMeeting-2024-01-17 https://bugs.ruby-lang.org/issues/20075 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2024/01/17 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 2024/01/14. 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/

9 8

[ruby-core:111342] [Ruby master Bug#19246] Rebuilding the loaded feature index much slower in Ruby 3.1
by thomthom (Thomas Thomassen) 17 Jan '24

17 Jan '24

Issue #19246 has been reported by thomthom (Thomas Thomassen). ---------------------------------------- Bug #19246: Rebuilding the loaded feature index much slower in Ruby 3.1 https://bugs.ruby-lang.org/issues/19246 * Author: thomthom (Thomas Thomassen) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Some background to this issue: (This is a case that is unconventional usage of Ruby, but I hope you bear with me.) We ship the Ruby interpreter with our desktop applications for plugin support in our application (SketchUp). One feature we have had since, at least 2006 (maybe earlier-hard to track history beyond that) is that we had a custom alternate `require` method: `Sketchup.require`. This allows the users of our API to load encrypted Ruby files. This originally used `rb_provide` to add the path to the encrypted file into the list of loaded feature. However, somewhere between Ruby 2.2 and 2.5 there was some string optimisations made and the function `rb_provide` would not use a copy of the string passed to it. Instead it just held on to a pointer reference. In our case that string came from user-land, being passed in from `Sketchup.require` and would eventually be garbage collected and cause access violation crashes. To work around that we changed our custom `Sketchup.require` to push to `$LOADED_FEATURES` directly. There was a small penalty to the index being rebuilt after that, but it was negligible. Recently we tried to upgrade the Ruby interpreter in our application from 2.7 to 3.1 and found a major performance reduction when using our `Sketchup.require. As in, a plugin that would load in half a second would now spend 30 seconds. From https://bugs.ruby-lang.org/issues/18452 it sounds like there is _some_ expected extra penalty due to changes in how the index is built. But should it really be this much? Example minimal repro to simulate the issue: ``` # frozen_string_literal: true require 'benchmark' iterations = 200 foo_files = iterations.times.map { |i| "#{__dir__}/tmp/foo-#{i}.rb" } foo_files.each { |f| File.write(f, "") } bar_files = iterations.times.map { |i| "#{__dir__}/tmp/bar-#{i}.rb" } bar_files.each { |f| File.write(f, "") } biz_files = iterations.times.map { |i| "#{__dir__}/tmp/biz-#{i}.rb" } biz_files.each { |f| File.write(f, "") } Benchmark.bm do |x| x.report('normal') { foo_files.each { |file| require file } } x.report('loaded_features') { foo_files.each { |file| require file $LOADED_FEATURES << "#{file}-fake.rb" } } x.report('normal again') { biz_files.each { |file| require file } } end ``` ``` C:\Users\Thomas\SourceTree\ruby-perf>ruby27.bat ruby 2.7.4p191 (2021-07-07 revision a21a3b7d23) [x64-mingw32] C:\Users\Thomas\SourceTree\ruby-perf>ruby test-require.rb user system total real normal 0.000000 0.031000 0.031000 ( 0.078483) loaded_features 0.015000 0.000000 0.015000 ( 0.038759) normal again 0.016000 0.032000 0.048000 ( 0.076940) ``` ``` C:\Users\Thomas\SourceTree\ruby-perf>ruby30.bat ruby 2.7.4p191 (2021-07-07 revision a21a3b7d23) [x64-mingw32] C:\Users\Thomas\SourceTree\ruby-perf>ruby test-require.rb user system total real normal 0.000000 0.031000 0.031000 ( 0.074733) loaded_features 0.032000 0.000000 0.032000 ( 0.038898) normal again 0.000000 0.047000 0.047000 ( 0.076343) ``` ``` C:\Users\Thomas\SourceTree\ruby-perf>ruby31.bat ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x64-mingw-ucrt] C:\Users\Thomas\SourceTree\ruby-perf>ruby test-require.rb user system total real normal 0.016000 0.031000 0.047000 ( 0.132633) loaded_features 1.969000 11.500000 13.469000 ( 18.395761) normal again 0.031000 0.125000 0.156000 ( 0.249130) ``` Right now we're exploring options to deal with this. Because the performance degradation is a blocker for us upgrading. We also have 16 years of plugins created by third party developer that makes it impossible for us to drop this feature. Some options as-is, none of which are ideal: 1. We revert to using `rb_provide` but ensure the string passed in is not owned by Ruby, instead building a list of strings that we keep around for the duration of the application process. The problem is that some of our plugin developers have on occasion released plugins that will touch `$LOADED_FEATURES`, and if such a plugin is installed on a user machine it might cause the application to become unresponsive for minutes. The other non-ideal issue with using `rb_provide` is that we're also using that in ways it wasn't really intended (from that I understand). And it's not an official API? 2. We create a separate way for our `Sketchup.require` to keep track of it's loaded features, but then that would diverge even more from the behaviour of `require`. Replicating `require` functionality is not trivial and would be prone to subtle errors and possible diverge. It also doesn't address our issue that there is code out there in existing plugins that touches `$LOADED_FEATURES`. (And it's not something we can just ask people to clean up. From previous experience old versions stick around for a long time and is very hard to purge from circulation.) I have two questions for the Ruby mantainers: 1. Would it be reasonable to see an API for adding/removing/checking `$LOADED_FEATURE` that would allow for a more ideal implementation of a custom `require` functionality? 2. Is the performance difference in rebuilding the loaded feature index really expected to be as high as what we're seeing? An increase of nearly 100 times? Is there something there that might be addressed to make the rebuild to be less expensive against? (This would really help to address our challenges with third party plugins occasionally touching the global.) -- https://bugs.ruby-lang.org/

9 21