[ruby-core:95634] [Ruby master Feature#16289] Reduce duplicated warnings for the change of Ruby 3 keyword arguments

[mame@ruby-lang.org]

Issue #16289 has been updated by mame (Yusuke Endoh).


> It leads a memory leak.

Theoretically, yes.  Even if iseqs of caller or callee are free'd, the corresponding records are not free'd.  But honestly I don't think it is worth elaborating the feature for some reasons:

(1) in practice, the case would be rare (to cause the leak, we need to repeatedly create iseq by using "eval" and trigger a warning in the iseq);
(2) the leak does not occur if a waring is not emitted (and it should be fixed); and
(3) this hack is only for Ruby 2.7.

Before implementing the patch, I discussed with ko1.  At first I was going to avoid the leak by adding some fields to iseq, but he objected the approach and recommended the above design.  Now I agree with him.


> And different warnings won't be suppressed too?

It was not intended, but it would be also very rare to trigger different keyword warnings in one call, I guess.

----------------------------------------
Feature #16289: Reduce duplicated warnings for the change of Ruby 3 keyword arguments
https://bugs.ruby-lang.org/issues/16289#change-82421

* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
## Problem

Currently, the interpreter emits 200 lines of warnings against the following program.

```ruby
def foo(**opt); end
100.times { foo({kw:1}) }
```

```
$ ./miniruby -e 'def foo(**opt); end; 100.times { foo({kw:1}) }'
-e:1: warning: The last argument is used as the keyword parameter
-e:1: warning: for `foo' defined here
-e:1: warning: The last argument is used as the keyword parameter
-e:1: warning: for `foo' defined here
-e:1: warning: The last argument is used as the keyword parameter
-e:1: warning: for `foo' defined here
...
```

In theory, the warnings are not harmful because they don't stop or interfere the execution.  But in practice, I'm afraid if they are annoying because they flush all console logs away.
I think that the warning is not needed if the call is already warned.


## Proposal

How about limiting the count of warnings to at most once for each pair of caller and callee?

I've created [a pull request](https://github.com/ruby/ruby/pull/2458).  It records all pairs of caller position and callee iseq when emitting a warning, and suppress the warning if the same pair of caller and callee is already warned.

What do you think?



-- 
https://bugs.ruby-lang.org/