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

[ruby-core:115196] [Ruby master Feature#19979] Allow methods to declare that they don't accept a block via `&nil`
by ufuk (Ufuk Kayserilioglu) 24 Jul '24

24 Jul '24

Issue #19979 has been reported by ufuk (Ufuk Kayserilioglu). ---------------------------------------- Feature #19979: Allow methods to declare that they don't accept a block via `&nil` https://bugs.ruby-lang.org/issues/19979 * Author: ufuk (Ufuk Kayserilioglu) * Status: Open * Priority: Normal ---------------------------------------- ## Abstract This feature proposes new syntax to allow methods to explicitly declare that they don't accept blocks, and makes passing of a block to such methods an error. ## Background In #15554, it was proposed to automatically detect methods that do not use the block passed to them, and to error if a block was passed to such methods. As far as I can tell, it was later on closed since #10499 solved a large part of the problem. That proposal has, as part of the dev meeting discussion, a proposal from @matz to allow methods to use `&nil` to explicitly declare that they don't accept a block. At the time, the proposal was trying to solve a bigger problem, so this sub-proposal was never considered seriously. However, notes in the proposal say: > 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) This proposal extracts that sub-proposal to make this a new language feature. ## Proposal In Ruby, it is always valid for the caller to pass a block to a method call, even if the callee is not expecting a block to be passed. This leads to subtle user errors, where the author of some code assumes a method call uses a block, but the block passed to the method call is silently ignored. The proposal is to introduce `&nil` at method declaration sites to mean "This method does not accept a block". This is symmetric to the ability to pass `&nil` at call sites to mean "I am not passing a block to this method call", which is sometimes useful when making `super` calls (since blocks are always implicitly passed). Explicitly, the proposal is to make the following behaviour be a part of Ruby: ```ruby def find(item = nil, &nil) # some implementation that doesn't call `yield` or `block_given?` end find { |i| i == 42 } # => ArgumentError: passing block to the method `find' that does not accept a block. ``` ## Implementation I assume the implementation would be a grammar change to make `&nil` valid at method declaration sites, as well as raising an `ArgumentError` for methods that are called with a block but are declared with `&nil`. ## Evaluation Since I don't have an implementation, I can't make a proper evaluation of the feature proposal. However, I would expect the language changes to be minimal with no runtime costs for methods that don't use the `&nil` syntax. ## Discussion This proposal has much smaller scope than #15554 so that the Ruby language can start giving library authors the ability to explicitly mark their methods as not accepting a block. This is fully backward compatible, since it is an opt-in behaviour and not an opt-out one. Future directions after this feature proposal could be a way to signal to the VM that any method in a file that doesn't explicitly use `yield`/`block_given?` or explicitly declared a block parameter should be treated as not accepting a block. This can be done via some kind of pragma similar to `frozen_string_literal`, or through other means. However, such future directions are beyond the scope of this proposal. ## Summary Adding the ability for methods to declare that they don't accept a block will make writing code against such methods safer and more resilient, and will prevent silently ignored behaviour that is often hard to catch or troubleshoot. -- https://bugs.ruby-lang.org/

9 20

[ruby-core:118670] [Ruby master Bug#20647] Invalid return in class/module body from within singleton class
by kddnewton (Kevin Newton) 24 Jul '24

24 Jul '24

Issue #20647 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20647: Invalid return in class/module body from within singleton class https://bugs.ruby-lang.org/issues/20647 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Currently, Ruby will raise a syntax error for invalid returns within class and module bodies, but skips it for singleton classes. I think we should be able to add this same error for singleton classes, as I believe these always raise a LocalJumpError. ```ruby class << Object return end ``` -- https://bugs.ruby-lang.org/

3 2

[ruby-core:118673] [Ruby master Feature#14919] Add String#byteinsert
by ufuk (Ufuk Kayserilioglu) 23 Jul '24

23 Jul '24

Issue #14919 has been updated by ufuk (Ufuk Kayserilioglu). Given that we now have [`String#bytesplice` since Ruby 3.2](https://bugs.ruby-lang.org/issues/18598), these kinds of operations should be possible using `"xxxxx".bytesplice(byte_pointer, 0, other)` to insert bytes of `other` at `byte_pointer` and `"xxxxx".bytesplice(byte_pointer, num, "")` to remove `num` bytes at `byte_pointer`. ---------------------------------------- Feature #14919: Add String#byteinsert https://bugs.ruby-lang.org/issues/14919#change-109204 * Author: aycabta (aycabta .) * Status: Open ---------------------------------------- It's important for multibyte String editing. Unicode grapheme characters sometimes have plural code points. In text editing, software sometimes should add a new code point to an existing grapheme character. String#byteinsert is important for it. I implemented by pure Ruby in my code. https://github.com/aycabta/reline/blob/b17e5fd61092adfd7e87d576301e4e19a4d9… -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118531] [Ruby master Feature#20624] Enhance `RubyVM::AbstractSyntaxTree::Node#locations` method and `RubyVM::AbstractSyntaxTree::Location` class
by yui-knk (Kaneko Yuichiro) 23 Jul '24

23 Jul '24

Issue #20624 has been reported by yui-knk (Kaneko Yuichiro). ---------------------------------------- Feature #20624: Enhance `RubyVM::AbstractSyntaxTree::Node#locations` method and `RubyVM::AbstractSyntaxTree::Location` class https://bugs.ruby-lang.org/issues/20624 * Author: yui-knk (Kaneko Yuichiro) * Status: Open ---------------------------------------- # Background It's revealed that single location information is not enough for some node types. For example, `Prism::IfNode` include these locations * `if_keyword_loc` * `then_keyword_loc` * `end_keyword_loc` * `location` (this is whole node location) I propose `RubyVM::AbstractSyntaxTree::Node#locations` method to provide multiple locations information, and `RubyVM::AbstractSyntaxTree::Location` class for location information. # Example ```ruby node = RubyVM::AbstractSyntaxTree.parse("1 + 2") node = node locs = node.locations loc = locs.first p node # => #<RubyVM::AbstractSyntaxTree::Node:SCOPE@1:0-1:5> p loc.class # => RubyVM::AbstractSyntaxTree::Location p [loc.first_lineno, loc.first_column, loc.last_lineno, loc.last_column] # => [1, 0, 1, 5] ``` # Interface * Add `RubyVM::AbstractSyntaxTree::Location` class which has these methods * `#first_lineno` * `#first_column` * `#last_lineno` * `#last_column` * Add `RubyVM::AbstractSyntaxTree::Node#locations` method which returns multiple location information of the node * The first location is same with the whole node location # Implementation https://github.com/yui-knk/ruby/tree/ast_locations -- https://bugs.ruby-lang.org/

3 3

[ruby-core:118660] [Ruby master Feature#20646] Improve Socket.tcp
by shioimm (Misaki Shioi) 23 Jul '24

23 Jul '24

Issue #20646 has been reported by shioimm (Misaki Shioi). ---------------------------------------- Feature #20646: Improve Socket.tcp https://bugs.ruby-lang.org/issues/20646 * Author: shioimm (Misaki Shioi) * Status: Open ---------------------------------------- This is a proposed improvement to `Socket.tcp`, which has implemented Happy Eyeballs version 2 (RFC8305) in [PR9374](https://github.com/ruby/ruby/pull/9374). 1. Background I implemented Happy Eyeballs version 2 (HEv2) for Socket.tcp in PR9374, but several issues have been identified: - `IO.select` waits for name resolution or connection establishment in v46w, but it does not consider the case where both events occur simultaneously when it returns a value. - In this case, Socket.tcp can only capture one event and needs to execute an unnecessary loop to capture the other one, calling `IO.select` one extra time. - `IO.select` waits for both IPv6/IPv4 name resolution (in start), but when it returns a value, it doesn't consider the case where name resolution for both address families is complete. - In this case, `Socket.tcp` can only obtain the addresses of one address family and needs to execute an unnecessary loop obtain the other addresses, calling `IO.select` one extra time. - The consideration for `connect_timeout` was insufficient. After initiating one or more connections, it raises a 'user specified timeout' after the `connect_timeout` period even if there were addresses that have been resolved and have not yet tried to connect. - It does not retry with another address in case of a connection failure. - It executes unnecessary state transitions even when an IP address is passed as the `host` argument. - The regex for IP addresses did not correctly specify the start and end. 2. Proposal & Outcome To overcome the aforementioned issues, this PR introduces the following changes: - Previously, each loop iteration represented a single state transition. This has been changed to execute all processes that meet the execution conditions within a single loop iteration. - This prevents unnecessary repeated loops and calling `IO.select` - Introduced logic to determine the timeout value set for `IO.select`. During the Resolution Delay and Connection Attempt Delay, the user-specified timeout is ignored. Otherwise, the timeout value is set to the larger of `resolv_timeout` and `connect_timeout`. - This ensures that the `connect_timeout` is only detected after attempting to connect to all resolved addresses. - Retry with another address in case of a connection failure. - This prevents unnecessary repeated loops upon connection failure. - Call `tcp_without_fast_fallback` when an IP address is passed as the host argument. - This prevents unnecessary state transitions when an IP address is passed. - Fixed regex for IP addresses. Additionally, the code has been reduced by over 100 lines, and redundancy has been minimized, which is expected to improve readability. 3. Performance No significant performance changes were observed in the happy case before and after the improvement. However, improvements in state transition deficiencies are expected to enhance performance in edge cases. ```ruby require 'socket' require 'benchmark' Benchmark.bmbm do |x| x.report('fast_fallback: true') do 30.times { Socket.tcp("www.ruby-lang.org", 80) } end x.report('fast_fallback: false') do # Ruby3.3時点と同じ 30.times { Socket.tcp("www.ruby-lang.org", 80, fast_fallback: false) } end end ``` Before: ``` ~/s/build ❯❯❯ ../install/bin/ruby ../ruby/test.rb user system total real fast_fallback: true 0.021315 0.040723 0.062038 ( 0.504866) fast_fallback: false 0.007553 0.026248 0.033801 ( 0.533211) ``` After: ``` ~/s/build ❯❯❯ ../install/bin/ruby ../ruby/test.rb user system total real fast_fallback: true 0.023081 0.040525 0.063606 ( 0.406219) fast_fallback: false 0.007302 0.025515 0.032817 ( 0.418680) ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:118483] [Ruby master Bug#20614] Integer#size returns incorrect values on 64-bit Windows
by surusek 22 Jul '24

22 Jul '24

Issue #20614 has been reported by surusek (Łukasz Sur). ---------------------------------------- Bug #20614: Integer#size returns incorrect values on 64-bit Windows https://bugs.ruby-lang.org/issues/20614 * Author: surusek (Łukasz Sur) * Status: Open * ruby -v: ruby 3.4.0dev (2024-07-08T11:00:01Z master 02c4f0c89d [x64-mswin64_140] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- According to the ruby/spec, `0.size` should return size of the machine word in bytes, but on x64-mswin64_140 (both release 3.3.3 and git revision 02c4f0c89d) it doesn't. Following example: ``` ruby a, b = 0.size, [0].pack('J').length puts a, b ``` should print two `8`s, but on x64-mswin64_140, a is `4`. Issue is most likely caused by use of `long` instead of `SIGNED_VALUE` in internal/fixnum.h and `fix_size` function in numeric.c, because on Windows, `long` is always a 32-bit number. -- https://bugs.ruby-lang.org/

6 9

[ruby-core:111448] [Ruby master Bug#19266] URI::Generic should use URI::RFC3986_PARSER instead of URI::DEFAULT_PARSER
by gareth (Gareth Adams) 22 Jul '24

22 Jul '24

Issue #19266 has been reported by gareth (Gareth Adams). ---------------------------------------- Bug #19266: URI::Generic should use URI::RFC3986_PARSER instead of URI::DEFAULT_PARSER https://bugs.ruby-lang.org/issues/19266 * Author: gareth (Gareth Adams) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [arm64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In June 2014, [`uri/common` was updated][1] to introduce a RFC3986-compliant parser (`URI::RFC3986_PARSER`) as an alternative to the previous RFC2396 parser, and common methods like `URI()` were updated to use that new parser by default. The only methods in `common` not updated were [`URI.extract` and `URI.regexp`][2] which are marked as obsolete. (The old parser was kept in the `DEFAULT_PARSER` constant despite it not being the default for those methods, presumably for backward compatibility.) However, similar [methods called on `URI::Generic`][3] were never updated to use this new parser. This means that methods like `URI::Generic.build` fail when given input that succeeds normally, and this also affects subclasses like URI::HTTP: ``` $ pry -r uri -r uri/common -r uri/generic [1] pry(main)> URI::Generic.build(host: "underscore_host.example") URI::InvalidComponentError: bad component(expected host component): underscore_host.example from /Users/gareth/.asdf/installs/ruby/3.1.3/lib/ruby/3.1.0/uri/generic.rb:591:in `check_host' [2] pry(main)> URI::HTTP.build(host: "underscore_host.example") URI::InvalidComponentError: bad component(expected host component): underscore_host.example from /Users/gareth/.asdf/installs/ruby/3.1.3/lib/ruby/3.1.0/uri/generic.rb:591:in `check_host' [3] pry(main)> URI("http://underscore_host.example") => #<URI::HTTP http://underscore_host.example> ``` `URI::Generic.new` allows a configurable `parser` positional argument to override the class' default parser, but other factory methods like `.build` don't allow this override. Arguably this doesn't cause problems because at least in the case above, the URI can be built with the polymorphic constructor, but having the option to build URIs from explicit named parts is useful, and leaving the outdated functionality in the `Generic` class is ambiguous. It's possible that the whole Generic class and its subclasses aren't intended to be used directly how I'm intending here, but there's nothing I could see that suggested this is the case. I'm not aware of the entire list of differences between RFC2396 and RFC3986. The relevant difference here is that in RFC2396 an individual segment of a host ([`domainlabel`s][4]) could only be `alphanum | alphanum *( alphanum | "-" ) alphanum`, whereas RFC3986 allows [hostnames][5] to include any of `ALPHA / DIGIT / "-" / "." / "_" / "~"`. It's possible that other differences might cause issues for developers, but since this has gone over 8 years without anyone else caring about this, this is definitely not especially urgent. [1]: https://github.com/ruby/ruby/commit/bb83f32dc3e0424d25fa4e55d8ff32b061320e41 [2]: https://github.com/ruby/ruby/blob/28a17436503c3c4cb7a35b423a894b697cd80da9/… [3]: https://github.com/ruby/ruby/blob/28a17436503c3c4cb7a35b423a894b697cd80da9/… [4]: https://www.rfc-editor.org/rfc/rfc2396#section-3.2.2 [5]: https://www.rfc-editor.org/rfc/rfc3986#page-13 -- https://bugs.ruby-lang.org/

4 8

[ruby-core:118656] [Ruby master Misc#20645] Github release version string changed format
by owlking (Marek Wysinski) 21 Jul '24

21 Jul '24

Issue #20645 has been reported by owlking (Marek Wysinski). ---------------------------------------- Misc #20645: Github release version string changed format https://bugs.ruby-lang.org/issues/20645 * Author: owlking (Marek Wysinski) * Status: Open * Assignee: k0kubun (Takashi Kokubun) ---------------------------------------- https://github.com/ruby/ruby/releases Up to the 3.3.2 release the releases were named with dots and without a v prefix. ruby 3.3.3 is released as "v3.3.3" and 3.3.4 is released as "v3_3_4". I noticed when my automatic ruby update github workflow, based on the github releases api stopped working. Is this an intentional change? Should I update my scripts? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:118653] [Ruby master Bug#20644] Requiring URI together with the Parser gem in Ruby 3.4.0dev
by koic (Koichi ITO) 21 Jul '24

21 Jul '24

Issue #20644 has been reported by koic (Koichi ITO). ---------------------------------------- Bug #20644: Requiring URI together with the Parser gem in Ruby 3.4.0dev https://bugs.ruby-lang.org/issues/20644 * Author: koic (Koichi ITO) * Status: Open * ruby -v: ruby 3.4.0dev (2024-07-21T04:00:38Z master c544f26726) [x86_64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Recently, `NameError` occurs when requiring URI together with the Parser gem in Ruby 3.4.0dev. ## Expected (Ruby 3.3.4) No errors occur in the URI gem: ```console $ ruby -rparser -ruri -e '' ``` ## Actual (Ruby 3.4.0dev) The following error occurs in the URI gem: ```console # Please run `gem i parser` if the Parser gem is not installed. $ ruby -rparser -ruri -e '' /Users/koic/.rbenv/versions/3.4-dev/lib/ruby/3.4.0+0/uri/common.rb:26:in 'Module#remove_const': constant URI::Parser not defined (NameError) remove_const(:Parser) if const_defined?(:Parser) ^^^^^^^^^^^^ from /Users/koic/.rbenv/versions/3.4-dev/lib/ruby/3.4.0+0/uri/common.rb:26:in 'URI.parser=' from /Users/koic/.rbenv/versions/3.4-dev/lib/ruby/3.4.0+0/uri/common.rb:46:in '<module:URI>' from /Users/koic/.rbenv/versions/3.4-dev/lib/ruby/3.4.0+0/uri/common.rb:15:in '<top (required)>' from /Users/koic/.rbenv/versions/3.4-dev/lib/ruby/3.4.0+0/uri.rb:94:in 'Kernel#require_relative' from /Users/koic/.rbenv/versions/3.4-dev/lib/ruby/3.4.0+0/uri.rb:94:in '<top (required)>' from <internal:/Users/koic/.rbenv/versions/3.4-dev/lib/ruby/3.4.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' from <internal:/Users/koic/.rbenv/versions/3.4-dev/lib/ruby/3.4.0+0/rubygems/core_ext/kernel_require.rb>:136:in 'Kernel#require' ``` Specifically, the CI for the Ruby 3.4 matrix in RuboCop fails: https://github.com/rubocop/rubocop/actions/runs/10026682635/job/27711287086 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:113352] [Ruby master Bug#19619] Endless method definition with parameters for an instance given as numbered parameters doesn't work
by okuramasafumi (Masafumi OKURA) 21 Jul '24

21 Jul '24

Issue #19619 has been reported by okuramasafumi (Masafumi OKURA). ---------------------------------------- Bug #19619: Endless method definition with parameters for an instance given as numbered parameters doesn't work https://bugs.ruby-lang.org/issues/19619 * Author: okuramasafumi (Masafumi OKURA) * Status: Open * Priority: Normal * ruby -v: 3.2.2 * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This works: ```ruby class Foo def bar(baz) = 'foo' end p Foo.new.bar('baz') ``` This also works: ```ruby o = Object.new o.tap { |obj| def obj.bar(baz) = 'foo' } p o.bar('baz') ``` Even this works: ```ruby o = Object.new o.tap { def _1.bar = 'foo' } p o.bar ``` But this DOESN'T work: ```ruby o = Object.new o.tap { def _1.bar(baz) = 'foo' } p o.bar('baz') ``` So, when we define a method with parameters on an instance given as numbered parameters, it doesn't work. If we change one condition (definition way, parameter existence, and so on), it works. -- https://bugs.ruby-lang.org/

4 4