September 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:119096] [Ruby master Bug#20720] prism incorrectly marks SuperNode as forwarding in some cases
by luke-gru (Luke Gruber) 07 Sep '24

07 Sep '24

Issue #20720 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #20720: prism incorrectly marks SuperNode as forwarding in some cases https://bugs.ruby-lang.org/issues/20720 * Author: luke-gru (Luke Gruber) * Status: Open * ruby -v: 3.4.0dev * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby class A def foo(*b, &block) end end class B < A def foo(...) super() puts "2" end end ``` results in: ``` ./ruby --parser=prism -I../ruby/lib -I. -I.ext/x86_64-linux -I.ext/common -r./x86_64-linux-fake ../ruby/test.rb -- raw disasm-------- trace: 8 trace: 1 <L000> [sp: 0, unremovable: 0, refcnt: 0] 0000 putself ( 284) 0001 invokesuperforward <calldata:, 0>, nil ( 284) * 0004 pop ( 284) trace: 1 0005 putself ( 285) 0006 putchilledstring "2" ( 285) 0008 opt_send_without_block <calldata:puts, 1> ( 285) trace: 10 0010 leave ( 286) --------------------- ../ruby/test.rb: ../ruby/test.rb:284: argument stack underflow (-1) (SyntaxError) ``` It should differentiate between ZSUPER type nodes and super nodes in this case. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:118831] [Ruby master Feature#20673] Enable native SOCKS support by default
by MatzFan (Brian Cohen) 06 Sep '24

06 Sep '24

Issue #20673 has been reported by MatzFan (Brian Cohen). ---------------------------------------- Feature #20673: Enable native SOCKS support by default https://bugs.ruby-lang.org/issues/20673 * Author: MatzFan (Brian Cohen) * Status: Open ---------------------------------------- I'd like to see future Rubies have native SOCKS support enabled by default. Currently Rubies must be compiled with the `--enable-socks=true` option in order to provide access to the `SOCKSSocket` class, through which network connections may be made via the SOCKS protocol. My proposal is simply to deprecate the `--enable-socks` option IFO of SOCKS support being enabled by default. Use cases: To the best of my knowledge, the most commonly used SOCKS proxies are [Dante](https://www.inet.no/dante/) and [Tor](https://torproject.org). I know little of the former, but the latter is used as an anonymity tool. For example, the Tor Browser (based on Firefox) is built on the `tor` SOCKS proxy. Users wishing to make requests through the SOCKS protocol (through one of these proxies or otherwise) must compile their own Ruby with SOCKS enabled, or install Dante/Tor and make requests through these via another tool - e.g. a Selenium-driven browser, suitably configured. Alternatively, a lower level library like `cURL` can be utilized. Discussion: Most users do not build their own Rubies, but instead use the standard Rubies available from Ruby managers like `rvm` or `rbenv` (in both production and CI environments). Users needing to use the SOCKS protocol natively with one of these Rubies are presently reliant on the [socksify](https://rubygems.org/gems/socksify) Ruby gem (> 60M downloads). Declaration: I am the gem's current maintainer. The gem was originally built to provide native SOCKS support to users of these 'standard' Rubies via patches to the `Net/HTTP` and other Ruby core libraries. The current gem patches the private method `Net::HTTP#connect` in order to achieve this. This is a brittle and highly undesirable state of affairs and all code built using `socksify` is of course subject to breakage with each new Ruby release. It is difficult to gauge the exact nature and extent of the user need, but of the 60M Socksify downloads 20M have taken place is the last few years since I became maintainer. I consider this a significant user base. Many other languages provide native SOCKS support - e.g. Python has [PySocks](https://pypi.org/project/PySocks/). Fundamentally, is there any reason NOT to enable SOCKS support - would it break anything? I'd dearly like to retire the Socksify 'hack' in due course and see Ruby join the list of languages that offer SOCKS support by default - in all future Rubies. Many thanks for your consideration. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:118930] [Ruby master Feature#20692] Rewrite Array#bsearch in Ruby
by sebyx07 (Sebastian Buza) 06 Sep '24

06 Sep '24

Issue #20692 has been reported by sebyx07 (Sebastian Buza). ---------------------------------------- Feature #20692: Rewrite Array#bsearch in Ruby https://bugs.ruby-lang.org/issues/20692 * Author: sebyx07 (Sebastian Buza) * Status: Open ---------------------------------------- inspired by https://bugs.ruby-lang.org/issues/20182 Benchmark results (average over 10000000 iterations): user system total real Original bsearch: 7.011691 0.000038 7.011729 ( 7.013117) Native bsearch: 2.809711 0.001000 2.810711 ( 2.812067) https://github.com/sebyx07/native_ruby/blob/master/lib/native_ruby/array/bs… I also created this gem: https://github.com/sebyx07/native_ruby/ - to load patches w/o depending on the ruby/master -- https://bugs.ruby-lang.org/

4 5

[ruby-core:118745] [Ruby master Misc#20658] Dropping the "Arm Neoverse (Ubuntu) server on RubyCI
by jaruga (Jun Aruga) 06 Sep '24

06 Sep '24

Issue #20658 has been reported by jaruga (Jun Aruga). ---------------------------------------- Misc #20658: Dropping the "Arm Neoverse (Ubuntu) server on RubyCI https://bugs.ruby-lang.org/issues/20658 * Author: jaruga (Jun Aruga) * Status: Open ---------------------------------------- ## Context On July 26 2024, 4 days ago, the person at Arm sponsoring a SSH-accessing Arm server via Works on Arm program told me that they could no longer sponsor the server **after 10th August 2024**. We have been using Equinix's Arm-based virtual machine on their cloud infrastructure[2] for the server right now. The person at Arm told me that Arm is actually scaling down their servers at Equinix within the Works on Arm program. While the person at Arm suggested using their cloud offerings listed on the [1] for paid or free tier, I need to take time to investigate how to continue to use Arm-based SSH-accessing servers continuously within the Works on Arm program if we want to continue to use it. At least we need to drop the Arm-based server that is named as "Arm Neoverse (Ubuntu)" on RubyCI until 10th August 2024.[3] ## Note for Ruby project commiters using the "Arm Neoverse (Ubuntu)" server Dear commiters, Please back up your files on the "Arm Neoverse (Ubuntu)" server if you have the files. After 10th August 2024, we cannot access to the server by SSH any more. ## Steps to drop the "Arm Neoverse (Ubuntu)" I plan to do the following tasks to drop the "Arm Neoverse (Ubuntu)". * Drop the "Arm Neoverse (Ubuntu)" on RubyCI. * Remove the content about the "Ubuntu arm neoverse" on [our Wiki page](https://github.com/ruby/ruby/wiki/CI-Servers). * Drop the content about Works on Arm on www.ruby-lang.org, which I added by the pull-request <https://github.com/ruby/www.ruby-lang.org/pull/3183>. Please let me know if you find any other task about this topic. [1] Works on Arm: https://www.arm.com/markets/computing-infrastructure/works-on-arm [2] Equinix: https://www.equinix.com/ [3] RubyCI: https://rubyci.org/ -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119022] [Ruby master Bug#20711] readline/reline duplicate display of prompt
by yogo1212 (Leon Busch-George) 06 Sep '24

06 Sep '24

Issue #20711 has been reported by yogo1212 (Leon Busch-George). ---------------------------------------- Bug #20711: readline/reline duplicate display of prompt https://bugs.ruby-lang.org/issues/20711 * Author: yogo1212 (Leon Busch-George) * Status: Open * ruby -v: ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ```ruby #!/usr/bin/env ruby require 'readline' prompt = "asdf: " default = "true" Readline.pre_input_hook = -> do Readline.insert_text "#{default}" Readline.redisplay Readline.pre_input_hook = nil end Readline.readline(prompt) ``` ``` prompt: trueprompt: ``` the cursor sits at the right place (behind the 'e' in 'true'). inserting a backslash causes the line to be cleared and fixes the display. expected display, correct in previous versions: ``` prompt: true ``` affected: ``` ruby 3.3.3 (2024-06-12 revision f1c7b6f435) [x86_64-linux] # from rbenv ``` unaffected: ``` ruby 3.0.7p220 (2024-04-23 revision 724a071175) [x86_64-linux] # RHEL 9 ruby 3.2.5 (2024-07-26 revision 31d0f1a2e7) [x86_64-linux] # Arch Linux package ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118969] [Ruby master Feature#20702] Add `Array#fetch_values`
by toy (Ivan Kuchin) 05 Sep '24

05 Sep '24

Issue #20702 has been reported by toy (Ivan Kuchin). ---------------------------------------- Feature #20702: Add `Array#fetch_values` https://bugs.ruby-lang.org/issues/20702 * Author: toy (Ivan Kuchin) * Status: Open ---------------------------------------- `Array` and `Hash` have matching methods to fetch: * One value using `[]` (`Array` also allows fetching multiple with range or two arguments) * One value with default or exception using `fetch` method * Multiple values using `values_at` method But only `Hash` has method `fetch_values` to fetch multiple values with fallback or raising an exception (see #10017). ```ruby hash = {a: 1, b: 2, c: 3} array = [1, 2, 3] hash[:b] # => 2 hash[:d] # => nil array[1] # => 2 array[4] # => nil hash.fetch(:b) # => 2 hash.fetch(:d) # => IndexError hash.fetch(:d){ 42 } # => 42 array.fetch(1) # => 2 array.fetch(4) # => IndexError array.fetch(4){ 42 } # => 42 hash.values_at(:b, :c) # => [2, 3] hash.values_at(:b, :d) # => [2, nil] array.values_at(1, 2) # => [2, 3] array.values_at(1, 4) # => [2, nil] hash.fetch_values(:b, :c) # => [2, 3] hash.fetch_values(:b, :d) # => IndexError hash.fetch_values(:b, :d){ 42 } # => [2, 42] # missing array.fetch_values(1, 2) # => [2, 3] array.fetch_values(1, 4) # => IndexError array.fetch_values(1, 4){ 42 } # => [2, 42] ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119033] [Ruby master Bug#20713] Ruby 3.3.5 triggers a deprecation warning with `require "json"`
by Bo98 (Bo Anderson) 05 Sep '24

05 Sep '24

Issue #20713 has been reported by Bo98 (Bo Anderson). ---------------------------------------- Bug #20713: Ruby 3.3.5 triggers a deprecation warning with `require "json"` https://bugs.ruby-lang.org/issues/20713 * Author: Bo98 (Bo Anderson) * Status: Open * ruby -v: 3.3.5 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Can be reproduced with `bundle exec ruby -e "require 'json'"`: ``` /opt/hostedtoolcache/Ruby/3.3.5/x64/lib/ruby/3.3.0/json/common.rb:3: warning: ostruct was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0. ``` Likely needs a backport of https://github.com/ruby/ruby/commit/066bd28cff75b752b0af90dce933fa382dee0406. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:119065] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by byroot (Jean Boussier) 05 Sep '24

05 Sep '24

Issue #15554 has been updated by byroot (Jean Boussier). > Warning category option like I think this is the better option as it build on top of an existing interface. And probably some existing warnings could be moved into that category. The way I see it, a `pedantic` category would be for all the warnings that have have chance to produce false positives. My hope is to be able to run my test suites with `$VERBOSE = true` and turn warnings into errors without having to filter any of them. ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-109644 * Author: ko1 (Koichi Sasada) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- # Abstract Warn or raise an ArgumentError if block is passed to a method which does not use a block. In other words, detect "block user methods" implicitly and only "block user methods" can accept a block. # Background Sometimes, we pass a block to a method which ignores the passed block accidentally. ``` def my_open(name) open(name) end # user hopes it works as Kernel#open which invokes a block with opened file. my_open(name){|f| important_work_with f } # but simply ignored... ``` To solve this issue, this feature request propose showing warnings or raising an exception on such case. Last developer's meeting, matz proposed `&nil` which declares this method never receive a block. It is explicit, but it is tough to add this `&nil` parameter declaration to all of methods (do you want to add it to `def []=(i, e, &nil)`?). (I agree `&nil` is valuable on some situations) # Spec ## Define "use a block" methods We need to define which method accepts a block and which method does not. * (1) method has a block parameter (`&b`) * (2) method body has `yield' * (3) method body has `super` (ZSUPER in internal terminology) or `super(...)` * (4) method body has singleton method (optional) (1) and (2) is very clear. I need to explain about (3) and (4). (3). `super` (ZSUPER) passes all parameters as arguments. So there is no surprise that which can accept `block`. However `super(...)` also passes a block if no explicit block passing (like `super(){}` or `super(&b)`) are written. I'm not sure we need to continue this strange specification, but to keep compatibility depending this spec, I add this rule. (4). surprisingly, the following code invoke a block: ``` def foo class << Object.new yield end end foo{ p :ok } #=> :ok ``` I'm also not sure we need to keep this spec, but to allow this spec, I added (4) rule. Strictly speaking, it is not required, but we don't keep the link from singleton class ISeq to lexical parent iseq now, so I added it. ## Exceptional cases A method called by `super` doesn`t warn warning even if this method doesn't use a block. The rule (3) can pass blocks easily and there are many methods don`t use a block. So my patch ignores callings by `super`. ## corner cases There are several cases to use block without (1)-(4) rules. ### `Proc.new/proc/lambda` without a block Now it was deprecated in r66772 (commit:9f1fb0a17febc59356d58cef5e98db61a3c03550). Related discussion: [Bug #15539] ### `block_given?` `block_given?` expects block, but I believe we use it with `yield` or a block parameter. If you know the usecase without them, please tell us. ### `yield` in `eval` We can't know `yield` (or (3), (4) rule) in an `eval` evaluating string at calling time. ``` def foo eval('yield`) end foo{} # at calling time, # we can't know the method foo can accept a block or not. ``` So I added a warning to use `yield` in `eval` like that: `test.rb:4: warning: use yield in eval will not be supported in Ruby 3.` Workaround is use a block parameter explicitly. ``` def foo &b eval('b.call') end foo{ p :ok } ``` # Implementation Strategy is: * [compile time] introduce `iseq::has_yield` field and check it if the iseq (or child iseq) contains `yield` (or something) * [calling time] if block is given, check `iseq::has_yield` flag and show warning (or raise an exception) https://gist.github.com/ko1/c9148ad0224bf5befa3cc76ed2220c0b On this patch, now it raises an error to make it easy to detect. It is easy to switch to show the warning. # Evaluation and discussion I tried to avoid ruby's tests. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786 Here is a patch. There are several patterns to avoid warnings. ## tests for `block_given?`, `Proc.new` (and similar) without block Add a dummy block parameter. It is test-specific issue. ## empty `each` Some tests add `each` methods do not `yield`, like: `def each; end`. Maybe test-specific issue, and adding a dummy block parameter. ## Subtyping / duck typing https://github.com/ruby/ruby/blob/c01a5ee85e2d6a7128cccafb143bfa694284ca87/… This `parse` method doesn't use `yield`, but other sub-type's `parse` methods use. ## `super` with `new` method https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… This method override `Class#new` method and introduce a hook with block (yield a block in this hook code). https://github.com/ruby/ruby/blob/trunk/lib/rubygems/package/tar_writer.rb#… In this method, call `super` and it also passing a block. However, called `initialize` doesn't use a block. ## Change robustness This change reduce robustness for API change. `Delegator` requires to support `__getobj__` for client classes. Now `__getobj__` should accept block but most of `__getobj__` clients do not call given block. https://github.com/ruby/ruby/blob/trunk/lib/delegate.rb#L80 This is because of delegator.rb's API change. https://gist.github.com/ko1/37483e7940cdc4390bf8eb0001883786#file-tests-pat… Nobu says calling block is not required (ignoring a block is no problem) so it is not a bug for delegator client classes. ## Found issues. ``` [ 2945/20449] Rinda::TestRingServer#test_do_reply = 0.00 s 1) Error: Rinda::TestRingServer#test_do_reply: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:635:in `test_do_reply' [ 2946/20449] Rinda::TestRingServer#test_do_reply_local = 0.00 s 2) Error: Rinda::TestRingServer#test_do_reply_local: ArgumentError: passing block to the method "with_timeout" (defined at /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:787) is never used. /home/ko1/src/ruby/trunk/test/rinda/test_rinda.rb:657:in `test_do_reply_local' [10024/20449] TestGemRequestSetGemDependencyAPI#test_platform_mswin = 0.01 s 3) Error: TestGemRequestSetGemDependencyAPI#test_platform_mswin: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:655:in `test_platform_mswin' [10025/20449] TestGemRequestSetGemDependencyAPI#test_platforms = 0.01 s 4) Error: TestGemRequestSetGemDependencyAPI#test_platforms: ArgumentError: passing block to the method "util_set_arch" (defined at /home/ko1/src/ruby/trunk/lib/rubygems/test_case.rb:1053) is never used. /home/ko1/src/ruby/trunk/test/rubygems/test_gem_request_set_gem_dependency_api.rb:711:in `test_platforms' ``` These 4 detection show the problem. `with_timeout` method (used in Rinda test) and `util_set_arch` method (used in Rubygems test) simply ignore the given block. So these tests are simply ignored. I reported them. (https://github.com/rubygems/rubygems/issues/2601) ## raise an error or show a warning? At least, Ruby 2.7 should show warning for this kind of violation with `-w`. How about for Ruby3? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118970] [Ruby master Feature#20703] Alias StringIO#string to StringIO#to_s
by sebyx07 (Sebastian Buza) 05 Sep '24

05 Sep '24

Issue #20703 has been reported by sebyx07 (Sebastian Buza). ---------------------------------------- Feature #20703: Alias StringIO#string to StringIO#to_s https://bugs.ruby-lang.org/issues/20703 * Author: sebyx07 (Sebastian Buza) * Status: Open ---------------------------------------- # Description Allow to use `StringIO.new('my string').to_s` to be the same as `StringIO.new('my string').string` IMO nobody really uses the current StringIO#to_s, so I don't think it will break other apps. That way you can also do interpolation easily ```ruby my_sio = StringIO.new('my string') puts "value: #{my_sio}" # value: my string ``` - issue: https://github.com/ruby/stringio/issues - pr: https://github.com/ruby/stringio/pull/103 -- https://bugs.ruby-lang.org/

4 4

[ruby-core:118994] [Ruby master Feature#20707] Move `Time#xmlschema` into core
by byroot (Jean Boussier) 05 Sep '24

05 Sep '24

Issue #20707 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20707: Move `Time#xmlschema` into core https://bugs.ruby-lang.org/issues/20707 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Performance Converting `Time` into `RFC3339 / ISO8601` representation is an significant hotspot for application that serialize data in JSON, XML or other formats. Right now this feature is currently available through the `time` default gem, so it rely on `Time#strftime`. While [`strftime` could certainly be optimized](https://github.com/ruby/ruby/pull/11508), ultimately it's a very generic API so can't make a lot of assumptions about the output. Whereas `ISO8601` is a very strict format, with very few dynamic part, so it's much easier for dedicated code to be well optimized, as the final size of the string can be computed upfront etc. [I experimented with this and was able to get a ~5x speedup with a fairly straightforward implementation](https://github.com/ruby/ruby/pull/11510). ``` compare-ruby: ruby 3.4.0dev (2024-08-29T13:11:40Z master 6b08a50a62) +YJIT [arm64-darwin23] built-ruby: ruby 3.4.0dev (2024-08-30T13:17:32Z native-xmlschema 34041ff71f) +YJIT [arm64-darwin23] warming up...... | |compare-ruby|built-ruby| |:-----------------------|-----------:|---------:| |time._xmlschema | 1.087M| 5.190M| | | -| 4.78x| |utc_time._xmlschema | 1.464M| 6.848M| | | -| 4.68x| |time._xmlschema(6) | 859.960k| 4.646M| | | -| 5.40x| |utc_time._xmlschema(6) | 1.080M| 5.917M| | | -| 5.48x| |time._xmlschema(9) | 893.909k| 4.668M| | | -| 5.22x| |utc_time._xmlschema(9) | 1.056M| 5.707M| | | -| 5.40x| ``` ### Usability Aside from the performance reason, `ISO8601` is so common that having this functionality built-in without needing to require anything would make sense to me. `xmlschema` is the most common reason why I require `time`, and in many case having it core would allow not to load it at all. -- https://bugs.ruby-lang.org/

2 1