[#98645] [Ruby master Misc#16933] DevelopersMeeting20200618Japan — mame@...

Issue #16933 has been reported by mame (Yusuke Endoh).

14 messages 2020/06/04

[#98663] [Ruby master Bug#16936] `make check TESTS="-n !/Foo#method/"` not skipping the test case — jaruga@...

Issue #16936 has been reported by jaruga (Jun Aruga).

13 messages 2020/06/05

[#98772] [Ruby master Bug#16959] Weakmap has specs and third-party usage despite being a private API — headius@...

Issue #16959 has been reported by headius (Charles Nutter).

13 messages 2020/06/12

[#98826] [Ruby master Feature#16963] Remove English.rb from Ruby 2.8/3.0 — hsbt@...

Issue #16963 has been reported by hsbt (Hiroshi SHIBATA).

9 messages 2020/06/16

[#98920] [Ruby master Bug#16978] Ruby should not use realpath for __FILE__ — v.ondruch@...

Issue #16978 has been reported by vo.x (Vit Ondruch).

24 messages 2020/06/23

[#98947] [Ruby master Feature#16986] Anonymous Struct literal — ko1@...

Issue #16986 has been reported by ko1 (Koichi Sasada).

66 messages 2020/06/26

[#98964] [Ruby master Feature#16989] Sets: need ♥️ — marcandre-ruby-core@...

SXNzdWUgIzE2OTg5IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IG1hcmNhbmRyZSAoTWFyYy1BbmRyZSBM

33 messages 2020/06/26

[#98965] [Ruby master Feature#16990] Sets: operators compatibility with Array — marcandre-ruby-core@...

Issue #16990 has been reported by marcandre (Marc-Andre Lafortune).

11 messages 2020/06/26

[#98968] [Ruby master Feature#16993] Sets: from hash keys using Hash#key_set — marcandre-ruby-core@...

Issue #16993 has been reported by marcandre (Marc-Andre Lafortune).

10 messages 2020/06/26

[#98997] [Ruby master Feature#17000] 2.7.2 turns off deprecation warnings by deafult — mame@...

Issue #17000 has been reported by mame (Yusuke Endoh).

16 messages 2020/06/30

[ruby-core:98759] [Ruby master Feature#16954] A new mode `Warning[:deprecated] = :error` for 2.7

From: fg@...
Date: 2020-06-12 08:53:57 UTC
List: ruby-core #98759
Issue #16954 has been updated by decuplet (Nikita Shilnikov).


For the record, I used Jeremy's gem to deal with all 2.7 warnings, it saved me a lot of time. My typical setup in tests looks like
```ruby
Warning.ignore(/some-gem-issuing-warnings-i-don-t-care-about/)
Warning.ignore(/another-gem/)
Warning.process { |w| raise RuntimeError, w } unless ENV['NO_RAISE_ON_WARNING']
```

----------------------------------------
Feature #16954: A new mode `Warning[:deprecated] = :error` for 2.7
https://bugs.ruby-lang.org/issues/16954#change-86116

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

(This is [what I already wrote in rubyonrails discourse](https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argument-pain-point/74980/43) but I repeat this to make this discussion easy.)

The plan of 3.0 keyword change (#14183) will prohibit the automatic conversion from the last Hash positional argument to keyword arguments, but will keep one from keywords to a positional argument.  This asymmetry made it difficult to fix code of argument forwarding.  @kamipo and @matsuda, Rails developers who did much work to support the 3.0 keyword change, found the following (simplified) case where a warning is emitted within Rails code although Rails is innocent.

Rails code:
```ruby
def target(**opt)       # warning: The called method `foo' is defined here
end

ruby2_keywords def lib_proxy(*args)
  target(*args)         # warning: Using the last argument as keyword parameters is deprecated; maybe ** should be added to the call
end
```

User application code (or gem code other than Rails):
```ruby
def app_proxy(*args) # actually, ruby2_keywords is required here
  lib_proxy(*args)
end

app_proxy(k: 42)
```

The user code attempts to pass keywords to Rails' `target` method via argument forwarding methods `app_proxy` and `lib_proxy`. Rails appropriately annotates `lib_proxy` with ruby2_keywords, but user code does not yet for `app_proxy`. Calling `app_proxy` converts the keywords to a normal Hash, so the final `target` method accepts them as a positional Hash, which leads to the warning. Unfortunately, the warning points only Rails code. So, the user sends a bug report to Rails and there is no good way for Rails developer to diagnose the issue.

@kamipo said that actual cases include rails/rails [#39562](https://github.com/rails/rails/issues/39562) and [#39227](https://github.com/rails/rails/issues/39227).

## Proposal

We can think of two solutions for this issue:

* Make the warning print a full backtrace (including `app_proxy` in the above case) so that they can debug the issue.
* Warn an event of automatic conversion from keywords to a positional one,  This will point the call of `app_proxy`, though it brings false positives.

Focus on the first solution in this ticket. (I'll create another ticket for the second one.)


There are two (orthogonal) approaches to make the first solution:

1. `Warning[:deprecated] = :error`, to make the warning into an error which produces a full backtrace (and stops the execution).
2. `Warning[:deprecated] = :debug`, to make the warning print a full backtrace (and continues the execution).

The former one is like `Thread.abort_on_exception = true`, and the latter is like `Thread.report_on_exception = true`.

A patch is not availrable yet.  (I'm asking @nobu to create a patch.)

## Discussion points

* We need to add this change into Ruby 2.7.2.  Is it acceptable?  (Matz has already agreed with this change, but we need to get approval from @nagachika, the 2.7 branch maintainer.)
* Which approach is preferrable?  Both?
* Are the names `:error` and `:debug` okay?  Or `:abort` and `:report` like `Thread.*_on_exception`?  Or other names?
* Should the commandline option `-W:deprecated` support the new modes?  Like `-W:deprecated=error`?



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

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread