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

[ruby-core:117868] [Ruby master Feature#15554] warn/error passing a block to a method which never use a block
by Eregon (Benoit Daloze) 14 May '24

14 May '24

Issue #15554 has been updated by Eregon (Benoit Daloze). We are discussing how to make opt-in. Because relaxed mode can miss cases (e.g. for methods with a common name), and some newer codebases/some Rubyists might want to use the stricter check (e.g. it enhances readability, ignored blocks by duck typing are ignored explicitly). One idea is command-line flag: `--strict-unused-block-warning` / `--pedantic-warnings` ? Or it could be a new warning category, e.g. `:pedantic`, disabled by default (similar to `performance` category). Maybe the name should be more specific? (e.g. `:strict_unused_block`). Or not? Thoughts on this? ---------------------------------------- Feature #15554: warn/error passing a block to a method which never use a block https://bugs.ruby-lang.org/issues/15554#change-108278 * 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:117838] [Ruby master Bug#20485] Simple use of Mutex and Fiber makes GC leak objects with singleton method
by skhrshin (Shintaro Sakahara) 13 May '24

13 May '24

Issue #20485 has been reported by skhrshin (Shintaro Sakahara). ---------------------------------------- Bug #20485: Simple use of Mutex and Fiber makes GC leak objects with singleton method https://bugs.ruby-lang.org/issues/20485 * Author: skhrshin (Shintaro Sakahara) * Status: Open * ruby -v: ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a possible memory leak which occurs only when several conditions are met. The code to reproduce the problem is below: ``` class Work def add_method singleton_class.define_method(:f) {} end end Mutex.new.synchronize { Fiber.new {}.resume } work = Work.new work.add_method work = nil GC.start num_objs = ObjectSpace.each_object.select { |o| o.is_a?(Work) rescue false }.size unless num_objs.zero? raise "NG" end ``` Expected result: The script exits normally. Actual result: RuntimeError "NG" is raised. If I remove `Mutex.new.synchronize { Fiber.new {}.resume }` or `work.add_method`, GC works as expected. Is there any problem at the way to use Mutex and Fiber in this code, or is it a bug due to Ruby? I tested ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] too and the result was same. -- https://bugs.ruby-lang.org/

2 13

[ruby-core:117588] [Ruby master Misc#20436] DevMeeting at RubyKaigi 2024
by ko1 (Koichi Sasada) 13 May '24

13 May '24

Issue #20436 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Misc #20436: DevMeeting at RubyKaigi 2024 https://bugs.ruby-lang.org/issues/20436 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- RubyKaigi 2024 will be at Okinawa, Japan, May 15th - 17th. We would like to try to hold a face-to-face dev meeting at Okinawa. (@matz will also participate!) * Date: 2023/05/14 (Tue.) 14:00-18:00 (The day before RubyKaigi) * Location: SAKURA innobase Okinawa, Haseko Naha Building 1F, 1-2-13 Matsuyama, Naha City, Okinawa * Near by RubyKaigi venue (not a RubyKaigi venue). * Japanese page: https://www.sakura.ad.jp/innobase/ ### Program * 1:45pm door open * 2:00pm opening and self introduction * 2:30pm discuss topics * 5:00pm closing and free time (closing time is depends on topics) * 5:50pm door close There are several RubyKaigi related events after that so let's continue on the party: * [RubyKaigi 2024 前夜祭 Asakusa.rb Welcome Drinkup - connpass](https://andpad.connpass.com/event/313590/) ### How to participate Open to any RubyKaigi attendees who have a commit bit or who have a topic they particularly want to discuss. Please write your name on this spreadsheet to count the number of participants. https://docs.google.com/spreadsheets/d/1qXuvXvigP80CFNwseJDKm2YNkpQmzSg9WSI… ### 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 2023/05/10. I'll ask Matz which should be discussed on this meeting and reorder them. - 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/

10 13

[ruby-core:117862] [Ruby master Bug#20487] 1..nil is giving range from 1 to inifinity in ruby greater than 2.6
by akshay_kakade (Akshay Kakade) 13 May '24

13 May '24

Issue #20487 has been reported by akshay_kakade (Akshay Kakade). ---------------------------------------- Bug #20487: 1..nil is giving range from 1 to inifinity in ruby greater than 2.6 https://bugs.ruby-lang.org/issues/20487 * Author: akshay_kakade (Akshay Kakade) * Status: Open * ruby -v: 3.2.0 * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- we consider nil as undefined value, value that is not present, we consider nil as falsey value as well, when we do nil.to_i it gives us zero..then with this rational 1..nil shouldn't give the range 1 to infinity, either we should make it as invalid or it should be converted to 1..0 script: (1..nil).each {|n| puts n } output 1 2 3 4 5 6 7 . . . . infinity -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117858] [Ruby master Bug#20486] Internal compiler error when compile CRuby with msys2-mingw64-gcc14
by nekoyama32767 (Jinsong Yu) 13 May '24

13 May '24

Issue #20486 has been reported by nekoyama32767 (Jinsong Yu). ---------------------------------------- Bug #20486: Internal compiler error when compile CRuby with msys2-mingw64-gcc14 https://bugs.ruby-lang.org/issues/20486 * Author: nekoyama32767 (Jinsong Yu) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Follow CRuby build guide in `https://github.com/ruby/ruby` Some file like `numerc.c` whill produce a `internal compiler error` when enble option `-fno-omit-frame-pointer` gcc version is ``` $ gcc --version gcc.exe (Rev2, Built by MSYS2 project) 14.1.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ``` ``` $ cc -fstack-protector-strong -fno-strict-overflow -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -I. -I.ext/include/x64-mingw32 -I./include -I. -I./prism -I./enc/unicode/15.0.0 -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Wdeprecated-declarations -Wdiv-by-zero -Wduplicated-cond -Wimplicit-function-declaration -Wimplicit-int -Wpointer-arith -Wwrite-strings -Wold-style-definition -Wimplicit-fallthrough=0 -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-packed-bitfield-compat -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wunused-variable -Wmisleading-indentation -Wundef -D_WIN32_WINNT=0x0600 -D__MINGW_USE_VC2005_COMPAT -c numeric.c -fno-omit-frame-pointer -freport-bug during RTL pass: dwarf2 numeric.c: In function 'rb_float_new_in_heap': numeric.c:1034:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2cfi.cc:2112 1034 | } | ^ Please submit a full bug report, with preprocessed source. See <https://github.com/msys2/MINGW-packages/issues> for instructions. ``` Without `-fno-omit-frame-pointer` option, compile will pass. OS: `MSYS_NT-10.0-22631` CPU: I9-14900HX -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117834] [Ruby master Feature#20483] More intuitive initialisation of null Range
by bodacious (Gavin Morrice) 12 May '24

12 May '24

Issue #20483 has been reported by bodacious (Gavin Morrice). ---------------------------------------- Feature #20483: More intuitive initialisation of null Range https://bugs.ruby-lang.org/issues/20483 * Author: bodacious (Gavin Morrice) * Status: Open ---------------------------------------- Hi all 👋🏻 I've come across cases where I want a method to return a Range. In some cases, the Range should be empty. I see from the documentation, that it's possible to initialise a null Range by passing in values where a is greater than b `Range.new(1, -1)`. I find this particular notation to be unclear, and likely to be discouraged by my team because it's unclear. I'm opening this discussion to see if there's any interest in support for a simpler notation for null (empty) Ranges. Something like: ``` ruby r = Range.new(nil) # notation not currently supported r.size # => 0 r.max # => nil r.min # => nil r.each { puts "This is never called" } ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:117833] [Ruby master Bug#20482] nil variables in a guard clause of a standalone => or in expression
by Soilent (Konstantin x) 12 May '24

12 May '24

Issue #20482 has been reported by Soilent (Konstantin x). ---------------------------------------- Bug #20482: nil variables in a guard clause of a standalone => or in expression https://bugs.ruby-lang.org/issues/20482 * Author: Soilent (Konstantin x) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [arm64-darwin23] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The following expression produces a TypeError, which is quite unexpected: ```ruby [1, 2] in a, b if b == 2*a ``` ``` x.rb:1:in `*': nil can't be coerced into Integer (TypeError) [1, 2] in a, b if b == 2*a ^ from x.rb:1:in `<main>' ``` The expression above should be equivalent to the following one, which works as expected: ```ruby case [1, 2] in a, b if b == 2*a true else false end # => true ``` Apologies in advance if this is intentional or has been reported before. -- https://bugs.ruby-lang.org/

2 3

[ruby-core:116940] [Ruby master Feature#20300] Hash: set value and get pre-existing value in one call
by AMomchilov (Alexander Momchilov) 11 May '24

11 May '24

Issue #20300 has been reported by AMomchilov (Alexander Momchilov). ---------------------------------------- Feature #20300: Hash: set value and get pre-existing value in one call https://bugs.ruby-lang.org/issues/20300 * Author: AMomchilov (Alexander Momchilov) * Status: Open ---------------------------------------- When using a Hash, sometimes you want to set a new value, *and* see what was already there. Today, you **have** to do this in two steps: ```ruby h = { k: "old value" } # 1. Do a look-up for `:k`. old_value = h[:k] # 2. Do another look-up for `:k`, even though we just did that! h[:k] = "new value" use(old_value) ``` This requires two separate `Hash` look-ups for `:k`. This is fine for symbols, but is expensive if computing `#hash` or `#eql?` is expensive for the key. It's impossible to work around this today from pure Ruby code. I propose adding `Hash#update_value`, which has semantics are similar to this Ruby snippet: ```ruby class Hash def update_value(key, new_value) old_value = self[key] self[key] = new_value old_value end end ``` ... except it'll be implemented in C, with modifications to `tbl_update` that achieves this with a hash-lookup. Here's a PR with a PoC implementation: https://github.com/ruby/ruby/pull/10092 -- https://bugs.ruby-lang.org/

8 18

[ruby-core:117831] [Ruby master Bug#20481] Untrusted Marshal data can overwrite class/module instance variables
by qnighy (Masaki Hara) 11 May '24

11 May '24

Issue #20481 has been reported by qnighy (Masaki Hara). ---------------------------------------- Bug #20481: Untrusted Marshal data can overwrite class/module instance variables https://bugs.ruby-lang.org/issues/20481 * Author: qnighy (Masaki Hara) * Status: Open * ruby -v: ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The following code snippet shows how class/module instance variables can be overwritten in Ruby. Checked on Ruby 3.3.1. ```ruby class <<Object; attr_reader :foo; end p Object.foo # => nil # Marshal.load("\x04\x08Ic\x0BObject\x06:\x09@fooi\x2F") # # => can't override instance variable of class `Object' (TypeError) # p Object.foo # # => nil Marshal.load("\x04\x08[\x07c\x0BObjectI@\x06\x06:\x09@fooi\x2F") # => [Object, Object] p Object.foo # => 42 ``` Although it is the program author's responsibility to trust Marshal data, [there was an attempt to disallow write to a class instance variable](https://github.com/ruby/ruby/commit/3fe939564fc5f4dde52a6b9bc385e… and it is considered a bug that one can circumvent this check. This bug was once submitted to HackerOne, just in case this is considered a security vulnerability, and it was concluded that the bug actually isn't. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:117815] [Ruby master Misc#17569] `uri` lib maintainership
by hsbt (Hiroshi SHIBATA) 09 May '24

09 May '24

Issue #17569 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed Assignee changed from akr (Akira Tanaka) to hsbt (Hiroshi SHIBATA) We have been merged the followings instead of https://github.com/ruby/uri/pull/15 * https://github.com/ruby/uri/pull/22 * https://github.com/ruby/uri/pull/26 * https://github.com/ruby/uri/pull/27 I'll close this. ---------------------------------------- Misc #17569: `uri` lib maintainership https://bugs.ruby-lang.org/issues/17569#change-108224 * Author: marcandre (Marc-Andre Lafortune) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I’d like to merge https://github.com/ruby/uri/pull/15 but it is an API change. I would release v1.0.0. @akr is the official maintainer of `uri`… Is he still interested in this role? Otherwise we could put “Ruby core team” in the listing… -- https://bugs.ruby-lang.org/

1 0