relax unused block warning for duck typing #10559
Conversation
if a method `foo` uses a block, other (unrelated) method `foo`
can receives a block. So try to relax the unused block warning
condition.
```ruby
class C0
def f = yield
end
class C1 < C0
def f = nil
end
[C0, C1].f{ block } # do not warn
```
| def f = nil | ||
| end | ||
| C1.new.f{} # do not warn on duck typing |
There was a problem hiding this comment.
Shouldn't this warn?
Because this call site never uses C0#f, and even more C0#f has never been called.
So I think this is warning too little.
From your example at https://bugs.ruby-lang.org/issues/15554#note-29 I thought the logic is "if at a call site we noticed one of the called methods accepts a block, then we don't warn if later methods don't accept a block". I think that's fair, but it is of course order-dependent and would still warn if the method not accepting a block is called first.
There was a problem hiding this comment.
An idea to address the order could be to print these warnings only on process exit, then the order wouldn't matter, as long as one call at a given call site would be to a method accepting a block it wouldn't warn, but would warn if none of them used the block, even if there are other methods of the same name defined as accepting a block.
ruby/ruby#10403 raised many "the block passed to" warnings. then idnored these warnings because some of them might have contain false positives. Now we can restore the warning condition because these false positives should have been addressed by these changes: ruby/ruby#10559 rails#51597 rails#51583
ruby/ruby#10403 raised many "the block passed to" warnings. then idnored these warnings because some of them might have contain false positives. Now we can restore the warning condition because these false positives should have been addressed by these changes: ruby/ruby#10559 rails#51597 rails#51583
ruby/ruby#10403 raised many "the block passed to" warnings. then idnored these warnings because some of them might have contain false positives. Now we can restore the warning condition because these false positives should have been addressed by these changes: ruby/ruby#10559 rails#51597 rails#51583
ruby/ruby#10403 raised many "the block passed to" warnings. then idnored these warnings because some of them might have contain false positives. Now we can restore the warning condition because these false positives should have been addressed by these changes: ruby/ruby#10559 rails#51597 rails#51583
ruby/ruby#10403 raised many "the block passed to" warnings. then idnored these warnings because some of them might have contain false positives. Now we can restore the warning condition because these false positives should have been addressed by these changes: ruby/ruby#10559 rails#51597 rails#51583
if a method
foouses a block, other (unrelated) methodfoocan receives a block. So try to relax the unused block warning condition.