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=-3.3 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY shortcircuit=no autolearn=no 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 AED4C1F5AE for ; Thu, 30 Jul 2020 18:16:51 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 63D99120B1D; Fri, 31 Jul 2020 03:16:20 +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 B15CE120B1C for ; Fri, 31 Jul 2020 03:16:18 +0900 (JST) Received: by filterdrecv-p3las1-559bd7b968-wk85c with SMTP id filterdrecv-p3las1-559bd7b968-wk85c-19-5F230E8D-5 2020-07-30 18:16:45.075628151 +0000 UTC m=+86435.809274862 Received: from herokuapp.com (unknown) by ismtpd0019p1iad2.sendgrid.net (SG) with ESMTP id RS705QDzRmyjMJ48x_VhGA for ; Thu, 30 Jul 2020 18:16:44.968 +0000 (UTC) Date: Thu, 30 Jul 2020 18:16:45 +0000 (UTC) From: headius@headius.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 75227 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 17055 X-Redmine-Issue-Author: jeremyevans0 X-Redmine-Sender: headius 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?FFqrkVUH+vvTO0v2jw+akFtsx0ctu2v3V2wlBAc+sNrKayn4gNxxTbI2tHXHgN?= =?us-ascii?Q?tdrxUaWkRrChvwB68dwNYBfyBr4idtBeVNv1kUZ?= =?us-ascii?Q?G3k++GlxMKy9Bv7gaHY6M0CahJsyAV4ApAEkBAI?= =?us-ascii?Q?COU08vi+YFR4nRS7K5jBG8oUFZJ6EResKFFGaB+?= =?us-ascii?Q?SLwajWunGOoXwtW6I=2FFiqEXjefeV3o2oAty1ueW?= =?us-ascii?Q?TOwDpmteKp79zNDaA=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 99401 Subject: [ruby-core:99401] [Ruby master Feature#17055] Allow suppressing uninitialized instance variable and method redefined verbose mode warnings 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 #17055 has been updated by headius (Charles Nutter). Another note: > In fact I wouldn't be surprised if on other Ruby implementations initializing led to better performance (e.g., no need to grow the ivar storage dynamically later, or change the shape/hidden class). JRuby will attempt to allocate a "right-sized" object at the first allocation by analyzing all methods in a given class and looking for instance variable accesses. There's no growing of any variable table in this case; the object is allocated to have at least six real Java fields, and those fields are populated directly using movs in the resulting assembly code. If our analysis is wrong, undetected variables will go into a separate dynamically-managed array, but this case is trivially easy. ---------------------------------------- Feature #17055: Allow suppressing uninitialized instance variable and method redefined verbose mode warnings https://bugs.ruby-lang.org/issues/17055#change-86844 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- These two verbose mode warnings are both fairly common and have good reasons why you would not want to warn about them in specific cases. Not initializing instance variables to nil can be much better for performance, and redefining methods without removing the method first is the only safe approach in multi-threaded code. There are reasons that you may want to issue verbose warnings by default in these cases. For uninitialized instance variables, it helps catch typos. For method redefinition, it could alert you that a method already exists when you didn't expect it to, such as when a file is loaded multiple times when it should only be loaded once. I propose we keep the default behavior the same, but offer the ability to opt-out of these warnings by defining methods. For uninitialized instance variables in verbose mode, I propose we call `expected_uninitialized_instance_variable?(iv)` on the object. If this method doesn't exist or returns false/nil, we issue the warning. If the method exists and returns true, we suppress the warning. Similarly, for redefined methods, we call `expected_redefined_method?(method_name)` on the class or module. If the method doesn't exist or returns false/nil, we issue the warning. If the method exists and returns true, we suppress the warning. This approach allows high performance code (uninitialized instance variables) and safe code (redefining methods without removing) to work without verbose mode warnings. I have implemented this support in a pull request: https://github.com/ruby/ruby/pull/3371 -- https://bugs.ruby-lang.org/