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-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS 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 5DF2A1F45A for ; Sat, 17 Aug 2019 01:54:59 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 7AAC3120A0A; Sat, 17 Aug 2019 10:54:51 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 794AC120956 for ; Sat, 17 Aug 2019 10:54:49 +0900 (JST) Received: by filter0173p3mdw1.sendgrid.net with SMTP id filter0173p3mdw1-27670-5D575E6C-8 2019-08-17 01:54:52.197395523 +0000 UTC m=+30881.647403688 Received: from herokuapp.com (unknown [54.89.44.2]) by ismtpd0036p1mdw1.sendgrid.net (SG) with ESMTP id M7DyL2kLRIGd2T1aeWeTEg for ; Sat, 17 Aug 2019 01:54:52.107 +0000 (UTC) Date: Sat, 17 Aug 2019 01:54:52 +0000 (UTC) From: pjrebsch@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 69944 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 16100 X-Redmine-Issue-Author: prebsch X-Redmine-Sender: prebsch 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?OkVt5Zh+3hTtQKCLZhVmYl+X5FFf8Trofpaa=2FXb7D29avNeGKDsU9NeAvcTcA6?= =?us-ascii?Q?qKS6ir=2FLxNlE107A35blc=2FRVsI7v52z0gO1ziEm?= =?us-ascii?Q?L0VV6kQL8fqlmhGbn0sc4=2FMVJr=2F3qSWSO+C=2Fd+I?= =?us-ascii?Q?9X8FUESL=2Ftgc+dBzmIf8mN4JaKJikjYaGF1H9mR?= =?us-ascii?Q?Q356au6lsNCRlEjVfim3f3gu5S0bc=2Fc8ubw=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 94396 Subject: [ruby-core:94396] [Ruby master Bug#16100] Visibility modifiers don't call super correctly when overridden in alternative ways 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 #16100 has been updated by prebsch (Patrick Rebsch). Thanks for the explanation, Jeremy. I *think* I understand now. I took a look at the source and made another example to help me understand. I see now that the inconsistency only arises with the argument-less call of the visibility modifier. ```ruby def test_private_visibility(klass, method_name) puts puts "Case: #{ klass } ##{ method_name } is private?" puts " #=> #{ klass.private_instance_methods.include?(method_name) }" end class Parent def self.private(*) puts "::private called from #{ self.name }" super end end class Child_1 < Parent private def child_instance_method; end end class Child_2 < Parent def child_instance_method; end private(:child_instance_method) end test_private_visibility(Child_1, :child_instance_method) test_private_visibility(Child_2, :child_instance_method) ``` ``` ::private called from Child_1 ::private called from Child_2 Case: Child_1 #child_instance_method is private? #=> false Case: Child_2 #child_instance_method is private? #=> true ``` The source code makes it clear that the argument-less version is dependent upon a scope. So if I understand you correctly, the call to `super` in `Parent` is what would be calling this, and since that is in the scope of `Parent`, the originating call from `Child_1` doesn't work because the scope doesn't match? ```c static VALUE set_visibility(int argc, const VALUE *argv, VALUE module, rb_method_visibility_t visi) { if (argc == 0) { rb_scope_visibility_set(visi); } else { set_method_visibility(module, argc, argv, visi); } return module; } ``` ---------------------------------------- Bug #16100: Visibility modifiers don't call super correctly when overridden in alternative ways https://bugs.ruby-lang.org/issues/16100#change-80813 * Author: prebsch (Patrick Rebsch) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: ruby 2.7.0dev (2019-08-14) [x86_64-darwin18] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- It seems that the method visibility modifiers don't call `super` correctly when they are overridden in certain ways. I expected the following examples to all behave the same since they are all being defined on the singleton class, but only the first operates correctly presumably because it is explicitly defined on the singleton class. I've reproduced this behavior with `2.7.0`, `2.6.3`, and `2.5.5`. ``` ruby def test_visibility(description, klass) puts "Case: #{ description }" puts " #=> #{ klass.private_instance_methods.include?(:private_method) }" puts end test_visibility('explicit', Class.new { def self.private(*); super; end private; def private_method; end }) test_visibility('opened singleton', Class.new { class << self def private(*); super; end end private; def private_method; end }) test_visibility('include/prepend to singleton', Class.new { module M def private(*); super; end end singleton_class.prepend(M) private; def private_method; end }) ``` ``` Case: explicit #=> true Case: opened singleton #=> false Case: include/prepend to singleton #=> false ``` -- https://bugs.ruby-lang.org/