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

[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

[ruby-core:118891] [Ruby master Feature#20684] Add optimized instructions for frozen literal Hash and Array
by etienne 05 Sep '24

05 Sep '24

Issue #20684 has been reported by etienne (Étienne Barrié). ---------------------------------------- Feature #20684: Add optimized instructions for frozen literal Hash and Array https://bugs.ruby-lang.org/issues/20684 * Author: etienne (Étienne Barrié) * Status: Open ---------------------------------------- # Context Methods that take empty arrays or empty hashes as default values allocate a new object each time the method is called without the argument. Often they don't mutate the parameter. To prevent an allocation, in performance critical sections, a constant is defined that holds a frozen hash or array, and the constant is defined as the default value for the parameter. Here are some examples: Rails: https://github.com/rails/rails/blob/607d61e884237c223c24c6f47efa0b561dd8b63… Roda: https://github.com/jeremyevans/roda/blob/102926a02dcabc9a31674e3cf98f049139… dry-rb: https://github.com/dry-rb/dry-container/blob/1ee41bb109455d06bf22ebcbd94b05… and many other gems: https://gist.github.com/casperisfine/47f22243d4ad203855256ef5bfae7979 Additionally when defining a frozen literal constant, we're currently inefficient because we store the literal in the bytecode, we dup it just to freeze it again. It doesn't amount to much but would be nice to avoid. # Proposal Introduce 2 new optimized instructions `opt_ary_freeze` and `opt_hash_freeze` that behave like `opt_str_freeze` for their respective types. If the freeze method hasn't been redefined, they simply push the frozen literal value on the stack. Like for `opt_str_freeze`, these instructions are added by the peephole optimizer when applicable. In the specific case of empty array and empty hash, we use a pre-allocated global empty frozen object to avoid retaining a distinct empty object each time. This will allow code like this: https://github.com/ruby/ruby/blob/566f2eb501d94d4047a9aad4af0d74c6a96f34a9/… to be shortened and simplified like this: ```diff diff --git i/lib/rubygems/resolver/api_set/gem_parser.rb w/lib/rubygems/resolver/api_set/gem_parser.rb index 643b857107..34146fd426 100644 --- i/lib/rubygems/resolver/api_set/gem_parser.rb +++ w/lib/rubygems/resolver/api_set/gem_parser.rb @@ -1,15 +1,12 @@ # frozen_string_literal: true class Gem::Resolver::APISet::GemParser - EMPTY_ARRAY = [].freeze - private_constant :EMPTY_ARRAY - def parse(line) version_and_platform, rest = line.split(" ", 2) version, platform = version_and_platform.split("-", 2) dependencies, requirements = rest.split("|", 2).map! {|s| s.split(",") } if rest - dependencies = dependencies ? dependencies.map! {|d| parse_dependency(d) } : EMPTY_ARRAY - requirements = requirements ? requirements.map! {|d| parse_dependency(d) } : EMPTY_ARRAY + dependencies = dependencies ? dependencies.map! {|d| parse_dependency(d) } : [].freeze + requirements = requirements ? requirements.map! {|d| parse_dependency(d) } : [].freeze [version, platform, dependencies, requirements] end ``` Overall it's a minor optimization but also a very simple patch and makes code nicer. PR pending. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:119052] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by ko1 (Koichi Sasada) 05 Sep '24

05 Sep '24

Issue #15554 has been updated by ko1 (Koichi Sasada). As @Eregon mentioned on #60 we need to discuss how to enable strict mode. https://hackmd.io/CoLraFp_QrqyHBcv3g8bVg?view#Feature-15554-warnerror-passi… Summary of proposed ways: * Environment variable (`RUBY_WARN_UNUSED_BLOCK_STRICTLY` for example) * ruby command option * `--strict-unused-block-warning` * `--pedantic-warning` * Warning category option like `Warning[:performance] = true` * `Warning[:pedantic]` * Special category for this option: `Warning[:strict_unused_block]` * (and they are enabled on command line option like: `ruby -W:pedantic`) ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-109629 * 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:118542] [Ruby master Bug#20627] `require` on Ractor should run on the main Ractor
by ko1 (Koichi Sasada) 05 Sep '24

05 Sep '24

Issue #20627 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Bug #20627: `require` on Ractor should run on the main Ractor https://bugs.ruby-lang.org/issues/20627 * Author: ko1 (Koichi Sasada) * Status: Open * Assignee: ko1 (Koichi Sasada) * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Now `require` on main Ractor is not allowed (raising error) but it is hard, especially for `autoload`. So let's allow `require` by running it on the main Ractor. ## Background On many libraries it is needed to run loading on the main Ractors because: 1. Setup constants with unshareable objects (such as `C = []`) are not allowed on non main Ractors. 2. Setup global variables and class variables are not allowed. `$LOADED_FEATURES` is also untouchable. 3. (maybe more reasons) So the `require` on non main Ractors is not allowed. However it is hard to program especially on `autoload`. Also dynamic `require` (`require` in methods) are not allowed too (`pp` method, for example). ## Proposal Allow `require` on non main Ractors by running `require` process on the main Ractor. ![](clipboard-202407111201-kaiem.png) (quoted on my talk at RubyKaigi 2024) ### `rb_ractor_interrupt_exec(target_ractor, func)` C-API Make a thread on `target_ractor` and run `func` (C function) on it. I think it is safe to expose on Ruby API because running `func` on a *newly created* thread (do not disturb running target threads). But now it is proposed as only (hidden) C-API. ### New Ractor methods - `Rcator.main?` returns Ractors - `Ractor.require(feature)` do `require` on the main Ractor These new methods are useful for users who override `require` method like [RubyGems](https://github.com/ruby/ruby/blob/master/lib/rubygems/core_ext/ke…. ```ruby alias orig_require require def require feature return Rator.require(feature) unless Ractor.main? # overriding require code end ``` Or we can prepend a module like: ``` Module.new do def require(feature) return Rator.require(feature) unless Ractor.main? super(feature) end Kernel.prepend self end ``` will support ractors for all overgrinding methods. But not sure it is acceptable to add additional one modules in ancestors by `prepend`. Also this technique doesn't support require overriding by prepending. ## Implementation https://github.com/ruby/ruby/pull/11142 (not matured yet) ---Files-------------------------------- clipboard-202407111201-kaiem.png (70.8 KB) -- https://bugs.ruby-lang.org/

2 2

[ruby-core:119048] [Ruby master Feature#16378] Support leading arguments together with ...
by jeremyevans0 (Jeremy Evans) 04 Sep '24

04 Sep '24

Issue #16378 has been updated by jeremyevans0 (Jeremy Evans). esad (Esad Hajdarevic) wrote in #note-21: > Is there a reason why this doesn't work with keyword arguments too? > > For example: > ``` > def foo(bar:, ...) > other(...) > end > ``` > > results in syntax error Keyword arguments are not leading arguments. Trying to support what you want was not in scope. I think trying to support what you want would significantly increase the complexity, especially if you wanted to support `def foo(arg, kwarg: , ...)` as well. You should use: ```ruby def foo(*, bar:, **, &) other(*, **, &) end ``` ---------------------------------------- Feature #16378: Support leading arguments together with ... https://bugs.ruby-lang.org/issues/16378#change-109626 * Author: Eregon (Benoit Daloze) * Status: Closed * Assignee: matz (Yukihiro Matsumoto) * Target version: 3.0 ---------------------------------------- I think this is very important, otherwise `...` can be used only very rarely. For instance, `method_missing` typically want to access the method name like: ```ruby def method_missing(name, ...) if name.to_s.end_with?('?') self[name] else fallback(name, ...) end end ``` See the original feature: https://bugs.ruby-lang.org/issues/16253#note-19. I think most people expect `def method_missing(name, ...)` to work. ---Files-------------------------------- ruby_2_7_lead_args_forwarding.patch (8.98 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119047] [Ruby master Feature#16378] Support leading arguments together with ...
by esad (Esad Hajdarevic) 04 Sep '24

04 Sep '24

Issue #16378 has been updated by esad (Esad Hajdarevic). Is there a reason why this doesn't work with keyword arguments too? For example: ``` def foo(bar:, ...) other(...) end ``` results in syntax error ---------------------------------------- Feature #16378: Support leading arguments together with ... https://bugs.ruby-lang.org/issues/16378#change-109625 * Author: Eregon (Benoit Daloze) * Status: Closed * Assignee: matz (Yukihiro Matsumoto) * Target version: 3.0 ---------------------------------------- I think this is very important, otherwise `...` can be used only very rarely. For instance, `method_missing` typically want to access the method name like: ```ruby def method_missing(name, ...) if name.to_s.end_with?('?') self[name] else fallback(name, ...) end end ``` See the original feature: https://bugs.ruby-lang.org/issues/16253#note-19. I think most people expect `def method_missing(name, ...)` to work. ---Files-------------------------------- ruby_2_7_lead_args_forwarding.patch (8.98 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118773] [Ruby master Misc#20660] DevMeeting-2024-09-05
by mame (Yusuke Endoh) 04 Sep '24

04 Sep '24

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

6 6

[ruby-core:118996] [Ruby master Bug#20708] EINTR while opening fifo isn't retried
by martin.dorey＠hds.com (Martin Dorey) 04 Sep '24

04 Sep '24

Issue #20708 has been reported by martin.dorey(a)hds.com (Martin Dorey). ---------------------------------------- Bug #20708: EINTR while opening fifo isn't retried https://bugs.ruby-lang.org/issues/20708 * Author: martin.dorey(a)hds.com (Martin Dorey) * Status: Open * ruby -v: ruby 3.4.0dev (2024-08-30T20:36:28Z master eef2121cf3) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I don't think this should fail: ``` martind@stormy:~/download/ruby$ rm -f /tmp/badger && mkfifo /tmp/badger && timeout 2 ./ruby --disable-gems -we 'fork() {}; IO.read("/tmp/badger")' -e:1:in 'IO.read': Interrupted system call @ rb_sysopen - /tmp/badger (Errno::EINTR) from -e:1:in '<main>' martind@stormy:~/download/ruby$ ``` The behavior changed with 2.6.0-preview3 compared to 2.6.0-preview2: ``` martind@stormy:~/download/ruby-2.6.0-preview2$ rm -f /tmp/badger && mkfifo /tmp/badger && timeout 2 ./ruby --disable-gems -we 'fork() {}; IO.read("/tmp/badger")' martind@stormy:~/download/ruby-2.6.0-preview3$ rm -f /tmp/badger && mkfifo /tmp/badger && timeout 2 ./ruby --disable-gems -we 'fork() {}; IO.read("/tmp/badger")' Traceback (most recent call last): 1: from -e:1:in `<main>' -e:1:in `read': Interrupted system call @ rb_sysopen - /tmp/badger (Errno::EINTR) martind@stormy:~/download/ruby-2.6.0-preview3$ ``` I don't know what the consequences would be, so I don't mean this as a serious suggestion: ``` martind@stormy:~/download/ruby$ git diff diff --git a/io.c b/io.c index 54b60b7357..590e8d11d7 100644 --- a/io.c +++ b/io.c @@ -6956,7 +6956,10 @@ sysopen_func(void *ptr) static inline int rb_sysopen_internal(struct sysopen_struct *data) { - int fd = IO_WITHOUT_GVL_INT(sysopen_func, data); + int fd; + do { + fd = IO_WITHOUT_GVL_INT(sysopen_func, data); + } while (fd < 0 && errno == EINTR); if (0 <= fd) rb_update_max_fd(fd); return fd; martind@stormy:~/download/ruby$ ``` ... but it fixes this particular test case, for me, with today's Ruby from github. There were negligible differences between 2.6.0-preview{2,3} in io.c but the SIGCHLD handling was changed. The test case is reliable for me on at least: Linux stormy 4.19.0-26-amd64 #1 SMP Debian 4.19.304-1 (2024-01-09) x86_64 GNU/Linux Linux moritz 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64 GNU/Linux I hope it's independent of the kernel, as: https://man7.org/linux/man-pages/man7/signal.7.html ... teaches: > otherwise the call fails with the error EINTR: ... > • open(2), if it can block (e.g., when opening a FIFO; see > fifo(7)). -- https://bugs.ruby-lang.org/

2 1