From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 333AF1F66F for ; Fri, 20 Nov 2020 05:31:49 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id DB318120B4E; Fri, 20 Nov 2020 14:31:02 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 18372120B4D for ; Fri, 20 Nov 2020 14:31:00 +0900 (JST) Received: by filterdrecv-p3mdw1-5f8d7bb6d9-fbsnf with SMTP id filterdrecv-p3mdw1-5f8d7bb6d9-fbsnf-21-5FB754BD-31 2020-11-20 05:31:41.663562648 +0000 UTC m=+291653.189370633 Received: from herokuapp.com (unknown) by ismtpd0095p1iad2.sendgrid.net (SG) with ESMTP id lM8WbZ2ZT52gX1TBwp5f-w for ; Fri, 20 Nov 2020 05:31:41.607 +0000 (UTC) Date: Fri, 20 Nov 2020 05:31:41 +0000 (UTC) From: shyouhei@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 76831 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17143 X-Redmine-Issue-Author: jeremyevans0 X-Redmine-Sender: shyouhei X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?jcfQDMoo=2FMGCmP3uu1SeyLQUxUPXq5PjHpHz3xSFn16y7IDOamJRULX9XuV1V2?= =?us-ascii?Q?ye+iPy880u9dZDo76o1hPKDR9KuWTo7K7T1lI=2Fw?= =?us-ascii?Q?2sGDXqAjNU9TXLdih7U=2Fe1L95lUVHWFcNKeltsr?= =?us-ascii?Q?zTBsJnlVs3LyCH7w6wrpm0Sze0pdh=2FqbraeoDwT?= =?us-ascii?Q?8kgPDoiDHb0nBUn34V=2FlwpcgkQTp8ULXBAAlr=2FW?= =?us-ascii?Q?bbchB6e0Hu2Iqnaz4=3D?= To: ruby-core@ruby-lang.org X-Entity-ID: b/2+PoftWZ6GuOu3b0IycA== X-ML-Name: ruby-core X-Mail-Count: 100957 Subject: [ruby-core:100957] [Ruby master Feature#17143] Improve support for warning categories X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #17143 has been updated by shyouhei (Shyouhei Urabe). Persuaded at today's developer meeting. I now think that :redefine shall be handled in other ways. The point is, it is the author's intention, not the end user's, that they wants to redefine a method without warnings. Asking everyone else to set RUBYOPT='-W:redefine' sounds just a wrong way to solve the problem. The intention must be clearly declared by the author into their code. We should have a dedicated method something like `Class#suppress_redefinition_of_this_symbol(sym)`. Deprecation is a different story (people did not intend to use a deprecated feature; core devs make them deprecated). I can understand the use of warning mechanism there. ---------------------------------------- Feature #17143: Improve support for warning categories https://bugs.ruby-lang.org/issues/17143#change-88614 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- Support was recently added for Warning.warn to accept a `category` keyword. However, the initial implementation was limited to having `rb_warn_deprecated` and `rb_warn_deprecated_to_remove` use the `:deprecated` value for the `category` keyword. It doesn't make sense to me to have a `category` keyword if it is only used for deprecation, so I propose we extend the support so that `Kernel#warn` accepts a category keyword (for Ruby-level warnings) and `rb_category_warn` and `rb_category_warning` functions be added to the C-API (for C-level warnings). I also propose that we change existing `rb_warn` and `rb_warning` calls to `rb_category_warn` and `rb_category_warning`, so that all warnings issued by core Ruby are issued with an appropriate category. I have implemented support for this in a pull request: https://github.com/ruby/ruby/pull/3508 -- https://bugs.ruby-lang.org/